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
Says who? See http://www.andraka.com/gallery.htm for examples of large designs
that use placement constraints extensively. The key is to use hierarchy. In
order to do so with the current tools though, you'll have to do the placement in
the bottom levels of your code, not in the floorplanner.
Anil Khanna wrote:
> Using placement constraints is okay if you are trying to meet timing on
> certain small sections of the designs AND you know if these are going to be
> the bottleneck. It is not feasible to do this if you have a big design that
> is using 90+% of the slices/LEs etc.
>
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 59676
Good luck even getting the structure out of the manufacturer though. Even if you do,
I think you'll find a good part of the delay is in the clock tree. Unless that is
characterized, you probably won't be able to infer much more than what the data sheet
tells you.
Jon Elson wrote:
> Ray Andraka wrote:
>
> >Rickman et al,
> >
> >This is indeed fairly common. The manufacturer specifies the interface timing
> >only relative to signals on that interface, not relative to the DSP clock. This
> >often shows up on memory interfaces intended for static async RAM memory, for
> >example. In that case, the timing is all relative to the address, write pulse
> >and data and nearly never in relation to a clock. As Rickman points out, there
> >is no valid assumption you can make about the relationship to the DSP clock
> >other than the fact that these signals are synchronous to the clock unless it is
> >specified in the data sheet. Where it is not, even the manufacturer can't tell
> >you what the timing is because they don't characterize it.
> >
> Well, just because the manufacturer isn't putting the info in the data
> sheets, and don't
> test for it, I suspect that you could get a rough description that could
> be quite helpful.
> Knowing, for instance, that the strobes will always follow a CPU clock
> by at least
> 1 ns, and never change than 5 nS after the clock, would make designing a
> synchronous
> memory/peripheral controller running from the same clock a lot simpler.
>
> If you can just get the roughest of descriptions of the clock vs.
> strobes circuitry, you
> can improve the system performance greatly, because you don't have to
> have ranked
> FFs on every strobe.
>
> Now, on the high speed stuff, with clock multipliers, etc. it can get
> quite complex, and
> a CPU swap to the next higher speed can throw everything off due to a
> change in clock
> multiplier. But, I gathered from the initial post that this wasn't a
> clock multiplied CPU.
>
> Jon
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 59677
I have not had any success using the TIG within the HDL to date, although I have
not tried it since 4.2.
Martin Euredjian wrote:
> Sure, I could use multi-cycle in the UCF (or TIF, for that matter). For
> maintainability (and reusability) purposes I wanted to include these and
> other constraints with the HDL file.
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Martin Euredjian
>
> To send private email:
> 0_0_0_0_@pacbell.net
> where
> "0_0_0_0_" = "martineu"
>
> "Anil Khanna" <anil_khanna@mentor.com> wrote in message
> news:3f4a72c4$1@solnews.wv.mentorg.com...
> > Hi Martin,
> >
> > TIG should work, if not, you could always try a MCP (multicycle path
> > constraint) if you know how many times your data is sampled.
> >
> > Anil
> >
> > "Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
> > message news:3f49e539@dnews.tpgi.com.au...
> > > Martin Euredjian wrote:
> > > > The constraint guide indicates that the TIG constraint can be used in
> > HDL
> > > > (Verilog in my current design). However, an attempt to use it
> produces
> > the
> > > > following error:
> > > >
> > > > ERROR:Xst:1582 - The constraint 'tig=' is not supported neither in
> BEGIN
> > > > MODEL/END section in the XCF file, nor in HDL code.
> > > >
> > > > I have not been able to find further information on this error message
> > or
> > > > issue in the Xilinx site. Does anyone know if TIG is truly supported
> in
> > > > HDL? I'd hate to place it in the UCF file, to me it feels much more
> > > > approprite to have this constraint move with the HDL source.
> > > >
> > > > The form I'm using is:
> > > >
> > > > // synthesis attribute TIG of <net_name> is "";
> > > >
> > > > As a point of interest, the nets in question are the output of the
> > registers
> > > > of a microprocessor interface. The values are only sampled a few
> times
> > per
> > > > second by the receiving module. There is not need to have any of
> these
> > nets
> > > > meet nanosecond level timing constraints as other parts of the design
> > must.
> > > > Is there a better approach than "TIG"?
> > >
> > > Hi Martin,
> > >
> > > I think this old thread answers your question:
> > >
> >
> http://groups.google.com/groups?threadm=3dbd0daa%241_1%40lon-news.intensive.
> > net
> > >
> > > Regards,
> > > Allan.
> > >
> >
> >
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 59678
The M512 has a much coarser granularity, and is not nearly as localized as the SRL16's in
Xilinx. This becomes very apparent with reloadable DA filters, as the size of the M512
makes for a less than optimum DA lut. In any event, to get the most from any given
architecture, you have to design to the architecture, hence my comment about staying in
whatever you are comfortable with.
Peter Sommerfeld wrote:
> I haven't used Xilinx parts so I don't know how an SRL is more
> reconfigurable than the Stratix's TriMatrix memories (ie M512, etc).
> Using a dual-port M512 in a design means I can use it as LUT and
> simultaneously reconfigure in through the other port. Why are you
> saying the SRL is the only reloadable LUT out there?
>
> -- Pete
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 59679
Or, you can use the fast carry chain for the and. The luts are (i0 xnor i1) and
(i2 xnor i3). Lut outputs feed into the muxcy sel inputs, muxcy di<='0' and ci
comes from previous muxcy co. First muxcy ci<='1', then your equality compare
comes out of the last muxcy. Works out faster once you go over about 20 bit
inputs.
rickman wrote:
> zhengyu wrote:
> >
> > I've got two quick question. I don't have FPGA yet, but I want someone to
> > offer me some quick comments
> >
> > 1. I have got to do some 64 bit integer comparison, actually I have to do up
> > to 64 comparisons at the same time, the output is whether there is any pair
> > that equals.
>
> This is not a question... :)
>
> Equality compares are easy. It uses a two input XOR for each bit with
> all the results being OR'd together. This will take 32 LUTs for the XOR
> and the first OR gate and 11 more LUTs to combine the rest for a total
> of 43 LUTs in four levels. If the design uses the "special" features
> that most chips have (ORing of LUTs within a CLB), you can use the LUTs
> in pairs or even groups of four and reduce the number of levels for
> speed.
>
> > 2. If I want to create an 16 bit address space, that would translate to 512
> > k bits, does Vertex II give enough
> > block RAM so I don't have to use SRAM to do that? What kind of latency
> > performance should I expect from
> > typical SRAM, is 5ns read access reasonable?? what is the performance of
> > block ram??
>
> Is that 16 bit address (64k words) of 8 bit words? Because 64k x 8 =
> 512K.
>
> You can get this much RAM in the VirtexII if you use the XC2V500 part.
> Or in the new Spartan3 you could use a XC3S1500. I am not sure which
> will be cheaper, but I bet it is the Spartan3.
>
> The speed of the block RAM will be much faster than anything external to
> the FPGA. The block ram will be synchronous and lends itself well to
> pipelined operations.
>
> A lot of how you design will be implemented will depend on your data
> flow which you have said nothing about. Think about how the storage
> will be orgainized and accessed. Obviously one large block of memory
> with one interface will not let you do 64 compares at one time. If you
> rate of performing these compares is not fast, you can use one compare
> logic block and run the different data through it sequentially. Then
> one memory could easily do the job.
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design URL http://www.arius.com
> 4 King Ave 301-682-7772 Voice
> Frederick, MD 21701-3110 301-682-7666 FAX
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 59680Ray Andraka wrote: > Says who? See http://www.andraka.com/gallery.htm for examples of large designs > that use placement constraints extensively. The key is to use hierarchy. In > order to do so with the current tools though, you'll have to do the placement in > the bottom levels of your code, not in the floorplanner. Send them to the Guggenheim next time they're having a De Stijl exhibition. http://www.artlex.com/ArtLex/d/destijl.html Cheers, Allan. > Anil Khanna wrote: > > >>Using placement constraints is okay if you are trying to meet timing on >>certain small sections of the designs AND you know if these are going to be >>the bottleneck. It is not feasible to do this if you have a big design that >>is using 90+% of the slices/LEs etc. >> > > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 59681
Ray Andraka wrote: > Says who? See http://www.andraka.com/gallery.htm for examples of large designs > that use placement constraints extensively. The key is to use hierarchy. In > order to do so with the current tools though, you'll have to do the placement in > the bottom levels of your code, not in the floorplanner. Ray's impressive designs are mostly regular structures, mostly data path. Placement in the bottom levels of code works well for such designs. When the critical paths are in complex control logic, such placement isn't a realistic alternative. Other techniques are more useful. FPGA designs are not all the same sorts of things. Different requirements lead to different usages of the parts and the tools. -- Phil HaysArticle: 59682
In article <3F4AE286.80E9CAE4@attbi.com>, Phil Hays <SpamPostmaster@attbi.com> wrote: >Ray's impressive designs are mostly regular structures, mostly data >path. Placement in the bottom levels of code works well for such >designs. When the critical paths are in complex control logic, such >placement isn't a realistic alternative. Other techniques are more >useful. FPGA designs are not all the same sorts of things. Different >requirements lead to different usages of the parts and the tools. However, the complex-control-logic hairballs are what simulated annealing and related FPGA placement algorithms are designed to do best. A common (and effective) technique is to hand-place the regular datapath, and then let the placement tool arrange the control logic around the periphery. -- Nicholas C. Weaver nweaver@cs.berkeley.eduArticle: 59683
[mbvanilla on ml300 with linux image.bin?] > It will indeed work - the demo bit file is just mbvanilla targetting the > V2MB1000. Just make sure you keep the address map the same, eg the > location of your main RAM bank, which the kernel expects to find at > 0x80000000, for 16 Mb. Also the bootloader expects there to be > AMD-style flash at 0xFF000000. The source of the bootloader comes with > the mbvanilla project so you should have no trouble changing that if > necessary. ml300 has (lots of things) + DDR RAM (no FLASH) it is possible to preload the RAM from compact flash, so there is no need for flash, and if the linux image expects to see the flash its a problem :( I really would not like to write a ip core that 'emulates' the non existing flash I have looked at mb ulinux several times, but while working on w2k workstation it looks very complicated to get all the things to compile. antti PS I also have memec board with S2 600E and comm160 module there it would possible be easier to get the mbvanilla and image.bin to work. but,,, the flash on p160comm is not AMD?Article: 59684
Hi, As Ray said, it actually implements 2-bit Carry Look Ahead per slice. Definitely, you can implement any other adder which is of interest to you using LUTs. Pls. go to Xilinx Project Navigator => Help => Online Documentation =>XST User Guide => HDL Coding Techniques to find various signed and Unsigned Adder Implementation. Regards, Sanjay "Ray Andraka" <ray@andraka.com> wrote in message news:3F4A8912.FCFFC489@andraka.com... > It infers a ripple carry adder using the fast carry chains. The FPGAs > have special logic for implementing fast ripple carry (they actually do a > 2 bit carry look-ahead in hardware, but that is invisible to the user). > Other carry schemes are forced to use the much slower general purpose > routing and logic. In most cases, the adder built using the fast carry > chains is not only the minimum area, it is also the maximum performance. > > Nagaraj wrote: > > > Hi all, > > I am using XST (ISE 5.1i sp3) for my logic synthesis. If I write a > > piece of VHDL code as in " c <= a + b ", an N-bit adder will be > > inferred (assuming a,b,c are N bits). > > As there are many types of adder algorithms/implementations > > available (like Carry Look Ahead, Carry Save etc.), I want to know > > which one does XST infer? Can I have a control over the type of adder > > ? > > > > Regards, > > Nagaraj > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email ray@andraka.com > http://www.andraka.com > > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759 > >Article: 59686
Hello, I was wondering if there were any *lower* limits on the clock frequency that can be used to clock FPGAs (in particular the Xilinx Virtex II : XC2V3000). I know there are certain kinds of high speed logic families using precharge-discharge operation, where the leakage sets a lower limit on operating speed. Is there such a limit for these FPGAs, and if so, what is it (ballpark figures are fine). Thanks, NitinArticle: 59687
Antti Lukats wrote: > [mbvanilla on ml300 with linux image.bin?] > >>It will indeed work - the demo bit file is just mbvanilla targetting the >>V2MB1000. Just make sure you keep the address map the same, eg the >>location of your main RAM bank, which the kernel expects to find at >>0x80000000, for 16 Mb. Also the bootloader expects there to be >>AMD-style flash at 0xFF000000. The source of the bootloader comes with >>the mbvanilla project so you should have no trouble changing that if >>necessary. > > > ml300 has (lots of things) + > DDR RAM (no FLASH) > it is possible to preload the RAM from compact flash, so there is no > need for flash, and if the linux image expects to see the flash its > a problem :( Yes that should be fine. You should could pre-load the ram from CF, then jump immediately to 0x80000000, skipping the bootloader entirely. > I really would not like to write a ip core that 'emulates' > the non existing flash Well it's just a Xilinx ext . mem controller core, nothing fancy there, but I get your point :) > I have looked at mb ulinux several times, but while working on w2k > workstation it looks very complicated to get all the things to compile. yeah.. building linux kernels under cygwin is not for the faint hearted! > > antti > PS I also have memec board with S2 600E and comm160 module there it > would possible be easier to get the mbvanilla and image.bin to work. That would be cool, haven't heard of anyone running uclinux on a spartan yet. > but,,, the flash on p160comm is not AMD? Correct, I think it's from Toshiba, but it implements the AMD command set. In recent progress (ie 20 minutes ago!), I just succesfully mounted a JFFS2 file system on the flash, so now microblaze uclinux supports wear-levelling flash-based persistent storage... next step is getting the xilinx ethernet mac working and integrated into mbvanilla, then see what sort of a job montavista did on the linux driver for it... Regards, JohnArticle: 59688
John Williams wrote: > Antti Lukats wrote: > >> [mbvanilla on ml300 with linux image.bin?] >> >>> It will indeed work - the demo bit file is just mbvanilla targetting >>> the V2MB1000. Just make sure you keep the address map the same, eg >>> the location of your main RAM bank, which the kernel expects to find >>> at 0x80000000, for 16 Mb. Also the bootloader expects there to be >>> AMD-style flash at 0xFF000000. The source of the bootloader comes >>> with the mbvanilla project so you should have no trouble changing >>> that if necessary. >> >> >> >> ml300 has (lots of things) + >> DDR RAM (no FLASH) >> it is possible to preload the RAM from compact flash, so there is no >> need for flash, and if the linux image expects to see the flash its >> a problem :( > > > Yes that should be fine. You should could pre-load the ram from CF, > then jump immediately to 0x80000000, skipping the bootloader entirely. Oh one problem with this approach, the demo kernel image includes the MTD flash drivers, and they will be expecting to see some flash at 0xff000000. Shouldn't be fatal, you might just get some complaints when it boots up. I'm happy to make a custom image for you to play with, just tell me how you want it configured. It only takes a few minutes. Regards, JohnArticle: 59689
>However, the complex-control-logic hairballs are what simulated >annealing and related FPGA placement algorithms are designed to do >best. A common (and effective) technique is to hand-place the regular >datapath, and then let the placement tool arrange the control logic >around the periphery. How good is the current software? Many years ago, I could, do a manual placement and automatic routing if far less time than the P&R tools took to do the whole job. My "complex-control-logic hairballs" were generally pretty simple, mostly one-hot state machines. Maybe some pipelining to help. (They probably have to be simple if you are going to co-exist with a well planned data path.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 59690
Hi Austin, Yes, you could make an edge detect which generates a reset pulse. I tried it. But if the clock is lost the reset pulse will go away long before the clock is back and then the DCM needs another reset. That reset will off course come when CLK_LOS goes off, but I can not trust the CLK_LOS because the open clk input picks up signal from another clock (BLVDS) and will often indicate that a clock is present. An auto reset for my applications take som FF's (shift register, delay to wait for lock signal after reset) and gates. Multiply that with four DCM's and suddenly a small Virtex-II is gotten even smaller. Off course you cannot cover all situations, and my telecom application is a little bit demanding. It is just that an Auto-Lock would have fit in so nicely! Yes, squeese that feature into the next - Virtex-III? Hakon "Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message news:3F4A1E0C.47FC0DE4@xilinx.com... > Hakon, > > How about an OR gate of the status bits indicating a failure to a flip > flop that genreates a one clock long reset pulse? > > Lots of logic? three gates and a FF or two? > > The 'Auto-Lock' suggestion is a good one. We will keep that in mind. > > AustinArticle: 59691
>As long as the voting circuit output is consistant LOW or HIGH, it >doesn't really matter, at least in the context given. If the voting >circuit output is metastable, then thats problematic. Everything I know about metastability says that looking for things like voting circuits is barking up the wrong tree. If anybody has a good example of some "fix", "kludge" or "hack" that actually works, please tell me/us and explain why. We all agree that waiting longer helps. Right? (Helps lots!) Consider a voting circuit. It adds a few gates between the first bank of 3 FFs and the next FF that captures the output of the voting logic. Compare that with the clean/simple case of FF-FF with minimal routing delays. The delay through the gates is working against an exponential in increased settling time. Even if the normal no-logic path used a LUT so the voting logic is free, there is still the extra delay of routing from nearby FFs over to the LUT. (The other two FFs won't be quite so close.) -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 59692
my manager said it couldn't be done. So just to prove him wrong :-) http://www.fpga4fun.com/PWM_DAC.html Well, pretty simple stuff anyway. Have fun. JeanArticle: 59693
Nitin Chandrachoodan wrote: > Hello, > > I was wondering if there were any *lower* limits on the clock > frequency that can be used to clock FPGAs (in particular the Xilinx > Virtex II : XC2V3000). I know there are certain kinds of high speed > logic families using precharge-discharge operation, where the leakage > sets a lower limit on operating speed. Is there such a limit for these > FPGAs, and if so, what is it (ballpark figures are fine). All FPGAs (including Virtex II) and other programmable logic devices I know about are static devices. That is, all FlipFlops inside are complete static ones suitable for a clock from 0 to Fmax. Even more, there is no clock required at all. However, some FPGAs might contain special units that could require a minimum clock. The DCMs of the Virtex II are such an example. But when you do not need them, it's no matter at all... Regards, MarioArticle: 59694
Peter Alfke wrote: > If you have to cope with frequency differences ( not just unknown phase > ), then a FIFO is your only choice. And you have to have a strategy for > FIFO overflow/underflow, which will inevitably happen. Exactly. And this requires as well that you (Eric) need some kind of a handshaking signal that tells the source when the FiFo is full (or almost full) and it needs to stop transferring more data therefore. Alternatively you might remove data at the receiver at a rate always (guaranteed) higher than the source rate. There you need a trivial FiFo with a depth of 1 (i.e. just a register). Regards, MarioArticle: 59695
Nitin Chandrachoodan wrote: > Hello, > > I was wondering if there were any *lower* limits on the clock > frequency that can be used to clock FPGAs (in particular the Xilinx > Virtex II : XC2V3000). I know there are certain kinds of high speed > logic families using precharge-discharge operation, where the leakage > sets a lower limit on operating speed. Is there such a limit for these > FPGAs, and if so, what is it (ballpark figures are fine). Most of the internal logic is (or gives the appearance of being) static. The DLLs and PLLs are an obvious exception. As long as you don't use a DLL or PLL, you can quite happily clock your logic all the way down to 0Hz. I do recall that one of the older families (Xilinx 4000e?) had a maximum active time for one of the strobes on a CLB ram, which would limit the lowest operating frequency. I think that might have been a bug, and it has been fixed in more modern parts. Regards, Allan.Article: 59696
rickman <spamgoeshere4@yahoo.com> writes: > I am working with the ACEX 1K30 and I don't understand the structure of > the IOE. The diagram clearly shows three FFs; data input, data output > and output enable. The three FFs even have different types of > connections to the routing. But in the text, they seem to be saying > that there is only a single FF in the IOE. > > Is there really only one FF in the IOE so that it can be either input or > output? Is the OE FF always in an LE rather than the IOE? Seems like > this would make for some trouble getting the timing in tight > situations. > Yeah - been there, done that - I had great fun making a 10KE do a 100MHz SDRAM interface meet timing, due to the single flipflop :-( Someone once described the 10KE datasheet to me as "less than totally transparent" or some such. The other gotcha is the implication that there is an asynch preset on the FF - in the text it then describes that the P&R software will automatically put an invertor fore and aft of the FF and use the async reset input (that does exist). Making a bit of a hash of your tco as a a result :-( I was not a happy bunny that day, and from that day forward have made a point of not looking at Altera's diagrams only reading the text... Commiserations :-( Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 59697
Hello all, I have a slightly interesting problem here, and I wanted to know if my approach has any hazards which I should be aware of. My design is for a CPLD, if that matters. I have a binary synchronous counter, I call Master_Counter, that I want to clock at 312.5kHz (1/128th my system clock of 40MHz). I generate my 1/128 Prescale_CLK by picking off the MSB of a 7-bit counter which is clocked at Sys_CLK frequency(40MHz). In my design, Master_Counter usage is multiplexed -- it will be used to time four separate signals (which are synchronous to the 40MHz Sys_CLK) all 26kHz or below. To be able to select which signal is timed, I route my 4 signals into a 4:1 MUX. My current approach is to use Prescale_CLK to gate the ENABLE on the counter, with Master_Counter getting clocked from the 40MHz Sys_CLK. Since I need to time one of the four signals, I am actually ANDing the output of the 4:1 MUX with the Prescale_CLK and that feeds the ENABLE pin on Master_Counter. From reading the c.a.fpga archives, I *think* this is the correct approach since I've read the CLK input itself should never be gated, only the ENABLE but I would appreciate any commentary. My other problem is dealing with reset/clear logic which could get complicated, since I need to make sure the counter is reset/ENABLED properly when the MUX is switched (which occurs asynchronous to the four signals). I have seen Mr. Alfke's circuit that allows you to switch asynchronous clocks, I'll look at that again for ideas. As usual, thanks! -- Jay.Article: 59698
Hi, Mario Trams wrote: > Alternatively you might remove data at the receiver at a rate always > (guaranteed) higher than the source rate. There you need a trivial > FiFo with a depth of 1 (i.e. just a register). the FiFo-depth of 1 is only enough if the read-speed the double (or faster) when the write speed. If you have only a littel bit more than you need a FiFo-depth of 2 or 3 (se the double/tribble-buffering on videoprojektors that translate 50Hz input-framrate (europa-PAL) into 60Hz LCD-framerate). @Eric : how long is an incomming datapacket an how long the delay (for addressing and others) between the datapackets ?? how big is the diferenz between the clocks ?? (more than 1%) if you have both answers you can calculate the needet FiFo-depth (+1 for savety) in my projekt i use 3 buffers(registers) with its own statemaschine in serias for this problem, if you are interisted on my code then mailto:vikinger@uni.de Regards, Erik -- sorry for my terible english, my favorit language is assemblerArticle: 59699
Erik Spaenig wrote: > Hi, > > Mario Trams wrote: >> Alternatively you might remove data at the receiver at a rate always >> (guaranteed) higher than the source rate. There you need a trivial >> FiFo with a depth of 1 (i.e. just a register). > > the FiFo-depth of 1 is only enough if the read-speed the double (or > faster) when the write speed. If you have only a littel bit more than you > need a FiFo-depth of 2 or 3 (se the double/tribble-buffering on > videoprojektors that translate 50Hz input-framrate (europa-PAL) into 60Hz > LCD-framerate). Ok, I agree that a depth of 2 is desired due to practical issues. Thanks, Mario
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