Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Sep 30, 9:02=A0am, nobody <cydrollin...@gmail.com> wrote: > The chip may be obsolete but my four > layer board design is not and will support a bga chip and GT > resources. You do realize that most chip families are not pinout-compatible with one another? IOW, a Spartan6 in 256BGA is not going to work on a board designed for a Spartan3AN? And as I tried to get you to understand on the Xilinx PicoBlaze forum -- there's no such thing as a "standardized FPGA platform" (as much as Xilinx would have you believe otherwise). An audio-processing design has very little in common with a video-processing system. You choose an FPGA and design a board to meet the product requirements. You don't try to make your product requirements fit any random board you might already have built. -aArticle: 143301
On Sep 30, 8:19=A0pm, nobody <cydrollin...@gmail.com> wrote: > Antti, > > You seem to need to slam my stuff as if it is incorrect, that's a > difference between you and I. My project as it stands is what it is > and suits my purpose, however others may find use of such a project > and am trying to make it available. Other boards and projects > mentioned on this forum are what they are and suit their purpose. But > when an individual makes remarks about obsolete, not useful, not > necessary and the like explanation is necessary. As engineers we are > to take the body of knowledge we have been allotted and use it, break > it, expand it and make a contribution. If younger engineers read our > comments for their enhancement they should be unbiased and factual as > possible. If one were to read over these post they might think that > there is no need for a four layer board and as you commented that is > just not true. I take offense with your comment about a "real board" > needing 6 - 10 layers, well, taken in jest, nope, not funny. Let us > try and keep our communication at as high technical level as possible. > > My points about this post's origination: 1. I have completed a project > that is affordable and can be built by a hobbyist. 2. Is there any > need for an open source project with these mentioned > capabilities? > > I appreciate all the comments on this post and has been very > educational. > > Cy Drollinger i did not say YOUR board is obsoleted. but that S3E should be considered "obsolete, NFND.." relax, you did what you needed, used IC what you had. do it 4, do 2 or 10, its place for everything.. boards of the complexity of your board "might be done" on two layers, not always possible, but some have succeeded in that. It "costs" more to design a two layer board then a 4 layer board (6 layer). not useful? you say it? You havent published anything real, that would make your board more useful then others, its not the board, it the supplementary things: documentation, software, examples, and support. if you do those very well, you can succeed in selling your product as well. sorry if you feel like threated unfair with my commentary, I tried to say what may help you make things better, but you go saying i am too hard in the comments, yes i am, and better so, you go stronger, and make it better next time, where it can be done better, i hope. sorry, if i see you put a CPLD onto low cost board without ANY reason for it, then its wasting resources..adding cost to the end user. sorry i did point it out. eh, keep on, smile. cheer up! The S3E "Sample Pack" board that Digilent did for Xilinx, is a REAL bad design, bad to the bones, much bad, really, and that was done for Xilinx by their official partner. your board is better if that makes you feel any better. Antti PS I just found two of those S3E sample pack boards, probably the best thing todo with them is to trash them giving them away is not a good idea, hm, maybe Altera would say me a nice word if i give them away? (because the xilinx s3e sample boards are anti-ads for Xilinx) PPS I had a 24 hour battle with Xilinx BMM error.. so please excuse my wording, you too Cy..Article: 143302
On Sep 30, 8:32=A0pm, Andy Peters <goo...@latke.net> wrote: > On Sep 30, 9:02=A0am, nobody <cydrollin...@gmail.com> wrote: > > > The chip may be obsolete but my four > > layer board design is not and will support a bga chip and GT > > resources. > > You do realize that most chip families are not pinout-compatible with > one another? IOW, a Spartan6 in 256BGA is not going to work on a board > designed for a Spartan3AN? > > And as I tried to get you to understand on the Xilinx PicoBlaze forum > -- there's no such thing as a "standardized FPGA platform" (as much as > Xilinx would have you believe otherwise). An audio-processing design > has very little in common with a video-processing system. > > You choose an FPGA and design a board to meet the product > requirements. You don't try to make your product requirements fit any > random board you might already have built. > > -a he probably refers to those small white connectors but what does the design has todo with MGT's is a bit mystery to me too AnttiArticle: 143303
LucienZ wrote:
> Hi everyone, I am a master student and this is my first post in this
> group. My research group is looking for a multicore embedded platform
> for deploying an in-house developed computer vision algorithm. I've
> checked some available development boards and now still weigh the
> ideas in my mind.
I might verify that the algorithm is amenable
to parallel processing by borrowing a rack
of servers before I took on building
the same thing on an fpga.
-- Mike Treseler
Article: 143304On Sep 30, 12:13=A0pm, "Antti.Luk...@googlemail.com" <antti.luk...@googlemail.com> wrote: > On Sep 30, 7:34=A0pm, "John Speth" <johnsp...@yahoo.com> wrote: > > > Can anyone recommend any good USB 2.0 IP block vendors? > > > We're looking to implement a virtual COM port on an Altera Cyclone III = part > > with NIOS. =A0The maximum target data rate is 500K bytes/sec device-to-= host on > > the CDC bulk endpoint. > > > So far we have identified potential candidates: Vreelin and SLS. > > > Thanks, John Speth. > > does CDC allow 500K, you sure? > most CDC compliant uarts tend to have poor performance > > Antti I have consistently observed > 4Mbps with a basic CDC/ACM and windows. This has been across different PC configurations. But as you elude this might not be guaranteed on the host (or the spec), just my empirical observations. chrisArticle: 143305
The PCIE2.0-SATA 6.0G host controller has been verified at V6 platform. plz mail me if more info. arcdoos@yahoo.comArticle: 143306
"Antti" <antti.lukats@googlemail.com> wrote in message news:215e9ec0-ae7c-41c3-800f-5af01af570f5@l13g2000yqb.googlegroups.com... > but no cake ;) > > anywhy, september 2009 is released > http://groups.google.com/group/antti-brain/files?hl=en > > in time, this time. > > Antti "Brain" gets better with each issue - I've even saved this one ! Look out Circuit Cellar. !!! Thanks Antti. Michael KellettArticle: 143307
Hello, I'm baffled as to why XST won't synthesize this using an FDR making use of the synchronous reset pin. Instead it's using an FDE and ANDing the reset with the Data. The problem is that it's hurting my timing. How can I force XST to use the FDR instead of this kludgy thing it's doing? And I'd rather not have to explicitly instantiate an FDR primitive. Below is my coding example. Thanks, Dale process(clk) is begin if (clk='1' and clk'event and clk_en = '1') then if (reset=Pol) then stored <= (others => '0'); elsif (control = '1') then stored <= d; end if; end if; end process;Article: 143308
On Thu, 1 Oct 2009 08:24:44 -0700 (PDT) Dale <dale.prather@gmail.com> wrote: > Hello, > I'm baffled as to why XST won't synthesize this using an FDR making > use of the synchronous reset pin. Instead it's using an FDE and > ANDing the reset with the Data. The problem is that it's hurting my > timing. How can I force XST to use the FDR instead of this kludgy > thing it's doing? And I'd rather not have to explicitly instantiate > an FDR primitive. Below is my coding example. > Thanks, > Dale > > > process(clk) is > begin > if (clk='1' and clk'event and clk_en = '1') > then if (reset=Pol) then > stored <= (others => '0'); > elsif (control = '1') then > stored <= d; > end if; > end if; > end process; It's giving you what you've asked it for. You've asked for the reset input to be active only when (clk_en='1'). But the actual reset pin, on the actual flop, supercedes the enable pin. If this logic is right, it can't be done the way you want it to. You'd have to put an AND gate driving the reset pin. There's no dedicated fast path to do that, so you'd get an AND gate in a different slice, and then a trip through general routing to take it into the reset, and that'll slaughter your timing. Also, if Pol isn't a constant at compile time, then you've also added an XNOR into the reset path. Same problem as above. What makes you think that your timing situation would be improved substantially by not going through the LUT for the reset logic? The difference between a trip through the LUT, and going around it into the D input of the flop is, if I recall, on the order of 300ps. Are your margins really that tight? -- Rob Gaddi, Highland Technology Email address is currently out of orderArticle: 143309
On Oct 1, 11:24=A0am, Dale <dale.prat...@gmail.com> wrote:
> Hello,
> I'm baffled as to why XST won't synthesize this using an FDR making
> use of the synchronous reset pin. =A0Instead it's using an FDE and
> ANDing the reset with the Data. =A0The problem is that it's hurting my
> timing. =A0How can I force XST to use the FDR instead of this kludgy
> thing it's doing? =A0And I'd rather not have to explicitly instantiate
> an FDR primitive. =A0Below is my coding example.
> Thanks,
> Dale
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 process(clk) is
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 begin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (clk=3D'1' and clk'eve=
nt and clk_en =3D '1') then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (reset=
=3DPol) then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 stored <=3D (others =3D> '0');
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 elsif (co=
ntrol =3D '1') then
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 stored <=3D d;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end process;
I'm pretty sure that FDR does not apply the clock enable to
the reset input. If you had:
process(clk) is
begin
if (clk=3D'1' and clk'event) then
if (reset=3DPol) then
stored <=3D (others =3D> '0');
elsif (control =3D '1' and clk_en =3D '1') then
stored <=3D d;
end if;
end if;
end process;
you might be able to use an FDR.
Article: 143310On Sep 30, 10:26=A0am, Antti <antti.luk...@googlemail.com> wrote: > but no cake ;) > > anywhy, september 2009 is releasedhttp://groups.google.com/group/antti-br= ain/files?hl=3Den > > in time, this time. > > Antti Hey Antti - thanks for the shout-out on my ARM FPGA board! I've been reading Antti-Brain for a while now and always appreciate the new stuff you're doing. Keep it up! EricArticle: 143311
On Oct 1, 8:45=A0pm, emeb <ebromba...@gmail.com> wrote: > On Sep 30, 10:26=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > but no cake ;) > > > anywhy, september 2009 is releasedhttp://groups.google.com/group/antti-= brain/files?hl=3Den > > > in time, this time. > > > Antti > > Hey Antti - thanks for the shout-out on my ARM FPGA board! I've been > reading Antti-Brain for a while now and always appreciate the new > stuff you're doing. Keep it up! > > Eric you are welcome, i highlite stuff that deserves it, in my opinion i did not have url in the brain, but i did refer to this project http://www.mikrocontroller.net/articles/Audio-DSP_mit_Spartan_3-FPGA it looks that it could be ported with very little work the arm-fpga- audio eh, that would be real cool.. i do not have time right now todo it myself maybe, but no promise AnttiArticle: 143312
On Oct 1, 11:01=A0am, "Antti.Luk...@googlemail.com" <antti.luk...@googlemail.com> wrote: > On Oct 1, 8:45=A0pm, emeb <ebromba...@gmail.com> wrote: > > > On Sep 30, 10:26=A0am, Antti <antti.luk...@googlemail.com> wrote: > > > > but no cake ;) > > > > anywhy, september 2009 is releasedhttp://groups.google.com/group/antt= i-brain/files?hl=3Den > > > > in time, this time. > > > > Antti > > > Hey Antti - thanks for the shout-out on my ARM FPGA board! I've been > > reading Antti-Brain for a while now and always appreciate the new > > stuff you're doing. Keep it up! > > > Eric > > you are welcome, i highlite stuff that deserves it, in my opinion > i did not have url in the brain, but i did refer to this projecthttp://ww= w.mikrocontroller.net/articles/Audio-DSP_mit_Spartan_3-FPGA > > it looks that it could be ported with very little work the arm-fpga- > audio > eh, that would be real cool.. i do not have time right now todo it > myself > maybe, but no promise > > Antti Interesting site. The project appears to have been around for a while (reference to ISE 6.2). I imagine it could be ported to my board without too much trouble. If one is trying to build audio processors or synthesizers then that changes the task from one of coding proper HDL targeting the S3E FPGA to one of coding proper assembly for the custom DSP they've created. Depends on what development environment you like best. EricArticle: 143313
> But I've seen > one design article (carried out at NXP, the Netherlands) that claims > they have implemented two ARM926EJ-S processors on a Xilinx Virtex 4 > FPGA chip. I am wondering what technologies enable this > implementation. The same technologies that enable any other CPU to be put on an FPGA. The ARM926EJ-S is no different, except that it will be a lot bigger and a lot slower, than other FPGA specific CPUs. > 1. How to implement one or more such ARM926EJ-S cores on a FPGA chip Talk to ARM, but you probably can't afford it. JonArticle: 143314
Hi guys,
This is most likely a problem with a really simple solution, but I've
spent the past two hours hacking away at it and gotten nowhere...
I'm designing some data acquisition hardware that (basically) measures
the time between a bunch of pulses, stores them in an SRAM chip, then a
microcontroller reads the acquired data back later on. If the MCU tries
to read from memory while an acquisition is in progress, it reads
garbage. The MCU communicates through a series of registers in the FPGA.
My plan was something along these lines:
- Memory addresses generated by an 18-bit binary counter
- MCU data bus is 8 bits wide
- A L->H edge on "LOAD_L" sets ADDRESS[7:0] to the value on the data
bus and resets the FULL flag.
- A L->H edge on "LOAD_H" sets ADDRESS[15:8] to the value on the data
bus and resets the FULL flag.
- A L->H edge on "LOAD_U" sets ADDRESS[17:16] to the value on the data
bus and resets the FULL flag.
- A L->H edge on "RESET" clears the counter to 0 and resets the FULL
flag.
- A L->H edge on "INCREMENT" increments the address. If the address
counter wraps around, the FULL flag is set.
This is the code I've got now:
~~~~
module AddressCounter(ADDR,INCREMENT,EMPTY,FULL,RESET,DATA,LOAD_U,
LOAD_H, LOAD_L);
// Current address
output reg [17:0] ADDR;
/// Empty/Full status
// EMPTY is 1 whenever ADDR == 0.
// FULL is 1 if the last INCREMENT caused the address counter to
roll over.
output EMPTY;
output reg FULL;
/// Control inputs
// INCREMENT: L->H edge causes address to increment
input INCREMENT;
// RESET: L->H edge causes ADDR and the FULL flag to be cleared.
input RESET;
// LOAD_[UHL]: L->H edge loads contents of DATA into the upper,
high or low byte
// of the counter register.
input LOAD_U, LOAD_H, LOAD_L;
// DATA: Data that is loaded in by LOAD_[UHL].
input [7:0] DATA;
/// EMPTY output logic
assign EMPTY = (ADDR == 0);
/// Counting logic
always @(posedge INCREMENT or posedge RESET or posedge LOAD_U or
posedge LOAD_H or posedge LOAD_L) begin
if (RESET) begin
// Reset -- clear ADDR to 0 and clear FULL flag
ADDR <= 0;
FULL <= 0;
end else begin
if (LOAD_L) begin
// Load Low Byte
ADDR[7:0] <= DATA;
FULL <= 0;
end else if (LOAD_H) begin
// Load High Byte
ADDR[15:8] <= DATA;
FULL <= 0;
end else if (LOAD_U) begin
// Load Upper Byte
ADDR[17:16] <= DATA[1:0];
FULL <= 0;
end else begin
// Not a load, must be an increment.
{FULL, ADDR} <= ADDR + 1'b1;
end
end
end
endmodule
~~~~
The problem is, this seems to upset Quartus:
Warning: Presettable and clearable registers converted to equivalent
circuits with latches. Registers power up to an undefined state, and
DEVCLRn places the registers in an undefined state.
If I expand this, there are warnings for "ADDR[0]~reg0" through "ADDR[17]
~reg0":
Warning (13310): Register "ADDR[0]~reg0" is converted into an equivalent
circuit using register "ADDR[0]~reg0_emulated" and latch "ADDR[0]
~reg0latch"
What I'd like to know is, is there a better way to do what I want to do?
By that I mean, one that doesn't infer latches, or perhaps a cleaner way
to achieve what I want (I'd certainly be interested in alternative
implementations of the wrap-around detection)?
Is it really that bad to have a latch-inference in this situation?
Thanks,
--
Phil.
usenet09@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "09" with the last two digits of the current
year.
Article: 143315On Oct 1, 9:53=A0pm, Jon <j...@beniston.com> wrote: > > But I've seen > > one design article (carried out at NXP, the Netherlands) that claims > > they have implemented two ARM926EJ-S processors on a Xilinx Virtex 4 > > FPGA chip. I am wondering what technologies enable this > > implementation. > > The same technologies that enable any other CPU to be put on an FPGA. > The ARM926EJ-S is no different, except that it will be a lot bigger > and a lot slower, than other FPGA specific CPUs. > > > 1. How to implement one or more such ARM926EJ-S cores on a FPGA chip > > Talk to ARM, but you probably can't afford it. > > Jon http://www.elektroniknet.de/home/embeddedsystems/news/n/d/ohne-lizenz-zum-e= igenen-arm-soc-1/Article: 143316
Philip Pemberton <usenet09@philpem.me.uk> wrote: < This is most likely a problem with a really simple solution, but I've < spent the past two hours hacking away at it and gotten nowhere... < I'm designing some data acquisition hardware that (basically) measures < the time between a bunch of pulses, stores them in an SRAM chip, then a < microcontroller reads the acquired data back later on. If the MCU tries < to read from memory while an acquisition is in progress, it reads < garbage. The MCU communicates through a series of registers in the FPGA. It sounds like you need a FIFO, and are attempting to make one out of the SRAM. The FPGA tools usually know how to make a FIFO, at least when using the FPGA BRAM (block RAM). Also, the BRAM are dual port, which makes FIFO design easier. -- glenArticle: 143317
Read up on syncrhonous design. You need to do everything on a clock edge (i.e. posedge clk), and maybe reset (if it is asyncrhonous reset), but not on edges of other signals. AndyArticle: 143318
On Thu, 01 Oct 2009 19:31:22 +0000, glen herrmannsfeldt wrote:
> It sounds like you need a FIFO, and are attempting to make one out of
> the SRAM. The FPGA tools usually know how to make a FIFO, at least when
> using the FPGA BRAM (block RAM). Also, the BRAM are dual port, which
> makes FIFO design easier.
While a FIFO would be easier, it probably wouldn't have the storage
capacity required.
Say you have a stream of pulses like this:
___ ____ ___
___| |____| |____| |____ etc.
: : :
: t1 : t2 :
I need to record the "t" intervals, i.e. the time between rising edges.
The issue is, these intervals are around 3us (min 2us, max 4us or
thereabouts). They come from a rotating magnetic disc, which spins at
about 300RPM. 300RPM is 5 revolutions per second, or 200ms per
revolution. Assuming the intervals are all at the minimum point (2us),
that's 200,000 timing values.
The reference clock is 40MHz, meaning each 2us interval would cause a
count of 80 to be stored; a 4us interval would store 160. So for nominal
conditions, a 256 kilobyte SRAM is required.
I was under the impression that BlockRAM on Altera parts topped out at
about 64K on the lower-end Cyclones...
At this point, measuring the intervals isn't an issue -- I have more-or-
less working Verilog code for that. What I need to get working is the RAM
interface stuff...
Thanks,
--
Phil.
usenet09@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "09" with the last two digits of the current
year.
Article: 143319For all you not on our newsletter list we have now opened our pre- order list for the Spartan-6 based Drigmorn3 to everyone now. We are now completing our testing of our prototype batch and results are very good. We expect to build a big-ish batch in about 2 weeks time with shipping starting about a week after that. Initial boards will ship with CES grade silicon and that will continue until full release silicon is available in the dim and distant future. Details of Drigmorn3 - http://www.enterpoint.co.uk/component_replacements/drigmorn3.html John Adair Enterpoint Ltd.Article: 143320
On Oct 1, 1:22=A0pm, Philip Pemberton <usene...@philpem.me.uk> wrote:
> On Thu, 01 Oct 2009 19:31:22 +0000, glen herrmannsfeldt wrote:
> > It sounds like you need a FIFO, and are attempting to make one out of
> > the SRAM. =A0The FPGA tools usually know how to make a FIFO, at least w=
hen
> > using the FPGA BRAM (block RAM). =A0Also, the BRAM are dual port, which
> > makes FIFO design easier.
>
> While a FIFO would be easier, it probably wouldn't have the storage
> capacity required.
>
> Say you have a stream of pulses like this:
> =A0 =A0 ___ =A0 =A0 =A0____ =A0 =A0 =A0___
> ___| =A0 |____| =A0 =A0|____| =A0 |____ =A0 etc.
> =A0 =A0: =A0 =A0 =A0 =A0: =A0 =A0 =A0 =A0 :
> =A0 =A0: t1 =A0 =A0 : t2 =A0 =A0 =A0:
>
> I need to record the "t" intervals, i.e. the time between rising edges.
> The issue is, these intervals are around 3us (min 2us, max 4us or
> thereabouts). They come from a rotating magnetic disc, which spins at
> about 300RPM. 300RPM is 5 revolutions per second, or 200ms per
> revolution. Assuming the intervals are all at the minimum point (2us),
> that's 200,000 timing values.
>
> The reference clock is 40MHz, meaning each 2us interval would cause a
> count of 80 to be stored; a 4us interval would store 160. So for nominal
> conditions, a 256 kilobyte SRAM is required.
>
> I was under the impression that BlockRAM on Altera parts topped out at
> about 64K on the lower-end Cyclones...
>
> At this point, measuring the intervals isn't an issue -- I have more-or-
> less working Verilog code for that. What I need to get working is the RAM
> interface stuff...
>
> Thanks,
> --
> Phil.
> usene...@philpem.me.ukhttp://www.philpem.me.uk/
> If mail bounces, replace "09" with the last two digits of the current
> year.
As Andy pointed out, you need to think about how a flip-flop works.
It has
one clock input, yet you're trying to feed multiple control edges into
them.
Is your time base (?INCREMENT?) a fee running clock? If so, make your
load
signals operate in that clock domain. Maybe think have a higher speed
clock
than you increment signal that is the master clock and have everything
in
that domain:
always @(posedge fast_clk)
if (load_u)
....
else if (load_l)
...
else if (increment)
....
Make sure all the load/increment signals are pulses in the fast_clk
domain.
John Providenza
Article: 143321
On Thu, 01 Oct 2009 14:17:34 -0700, johnp wrote:
> As Andy pointed out, you need to think about how a flip-flop works. It
> has
> one clock input, yet you're trying to feed multiple control edges into
> them.
OK.
> Is your time base (?INCREMENT?) a fee running clock? If so, make your
> load
> signals operate in that clock domain.
The increment signal is generated when an edge appears on the input data
line -- one of the pulses I mentioned in my previous posting.
Basically:
module top(CLK40MHZ, DATA, RAM_ADDRESS, ...);
(...)
wire INCREMENT = DATA;
(...)
endmodule
Like I said, this thing talks to a disc drive. The 40MHz clock is used to
derive other clocks (e.g. 20MHz, 10MHz acq clocks, the 500Hz head
stepping pulses), and also as the reference for measuring the time
between the data pulses.
I think you and Andy are both right here -- I'm going to do some reading
up. My "working" read code only worked on testbench because it wasn't
simulating the effect of DATA_IN being on a separate clock domain... It
actually *doesn't* work on physical hardware.
Although I'm surprised I never thought of pulling INCREMENT in and using
it (effectively) as a clock enable... Maybe I've been taking too many
examples from old Xilinx manuals...
Thanks,
--
Phil.
usenet09@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "09" with the last two digits of the current
year.
Article: 143322On Oct 1, 3:45=A0pm, Philip Pemberton <usene...@philpem.me.uk> wrote: > > Although I'm surprised I never thought of pulling INCREMENT in and using > it (effectively) as a clock enable... Maybe I've been taking too many > examples from old Xilinx manuals... > > Thanks, > -- > Phil. Phil, please do not blame your bad habits on Xilinx, always a strong advocate of synchronous design methods. Peter Alfke, formerly associated with Xilinx.Article: 143323
Peter Alfke <alfke@sbcglobal.net> wrote: < On Oct 1, 3:45?pm, Philip Pemberton <usene...@philpem.me.uk> wrote: <> Although I'm surprised I never thought of pulling INCREMENT in and using <> it (effectively) as a clock enable... Maybe I've been taking too many <> examples from old Xilinx manuals... < Phil, please do not blame your bad habits on Xilinx, < always a strong advocate of synchronous design methods. < Peter Alfke, formerly associated with Xilinx. I am not so sure how to read it, but I didn't read it as Xilinx being against synchronous design. It seems that he has multiple clock domains, which always complicates synchronous logic. Are there any Xilinx examples for generating a FIFO using external RAM? That would seem to be one solution to the problem. More usual would be a big enough FIFO in the FPGA, and then external logic to extract data fast enough that it doesn't overflow. -- glenArticle: 143324
> http://www.elektroniknet.de/home/embeddedsystems/news/n/d/ohne-lizenz... That's not a 926 though, is it? Jon
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z