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
Tim wrote: > Pack flops into IOBs via switches to the mapper. From memory > it is something like '-pr b'. Run map with no arguments to get > the switch list. > > Virtex designs use regular flops in the IOBs, unlike 4K, etc., which > had magic IFD/OFD flops. > > "Marko" <cantsay@here.com> wrote in message > news:3bc9bc39.59939438@dfiatx1-snr1.gtei.net... > > I am targeting Xilinx Virtex II with Verilog in an ISE4.1i > > environment. I want to instantiate (or infer) a single IOB which has > > I/O capability, registered output, tristate output control, and > > registered input. Both registers can use the same clock. > > > > I expected to find a design element in Xilinx's Library Guide, but > > there is none. > > > > All of my attempts so far result in one or both registers being moved > > out of the IOB into a CLB. This won't work with my speed > > requirements. > > > > TIA > > mchampion@Xbigfoot.com (remove the X to send me email) Its also possible to use the UCF constraint: INST "your_ff" IOB = <TRUE | FALSE>; which has priority over the MAP flag. Useful if e.g. you have 2 FFs sourced from a pin but you only want one of them in the IOB. There are also these constraints to IOB FF packing (more important if the FFs are being inferred by synthesis): o No logic after an output FF, not even an inversion. o No logic before an input FF, ditto. o No feedback from an output FF to the reset of the logic. [synthesis optimisation can do this behind your back if you're not careful]. o If you want to pack both an input and an output FF then they must share a common initialisation signal. The 2 FFs can independently use this as a sync/async, set/reset. Note that this implies that you cannot have one FF with initialisation and the other without it.Article: 35701
Johan Ditmar schrieb:
>
> I implement two rotating shift registers (A and B) of three bits wide, one
> that is sensitive to the positive clock edge and one on the negative. I
> initialise one with the even bits of the pulse train ("101") and one with
> the odd ("010") and I let them run on the incoming clock.
Why do you want to use both clock edges? Cant you use a double frequency
clock signal?
> glitch free? As the output changes on both positive and negative clock edge,
Hmm, Iam no glitch expert. But AFAIK a decoder output (I your case the
2:1 MUX of the two shift registers) is always garantied to be glitch
free, IF only 1 input bit is changeing at a time (principle of gray
code). But on your mux, the select input AND one data input can change
on an clock egde so . . . .
Maybe you have to drop the MUX and try to feed the shift registers with
some kind of gray code which will be ORed.
--
MFG
Falk
Article: 35702Andy Peters schrieb: > > Falk Brunner wrote: > > > I mean, when the "Hello World" takes 100 Kb in C++, THIS IS REALLY CRAP. > > Aw, c'mon. You're talking about what happens when you use Visual C++ to > write a WINDOWS version of "Hello, World." Ahhh, yes ;-) > Write a short hello.cpp for your linux box, that runs on the command > line, and tell me how big it is. I aint got linux, yet ;-) But using TurboPascal, it takes 4k. -- MFG FalkArticle: 35703
my point exactly. It can be done, but is it really worth the price?
Phil Short wrote:
> Ray Andraka wrote:
> >
> > For these reasons, the self timed stuff to date has been for much
> > smaller designs than those commonly done with synchronous logic.
> >
> Seems like a lot of work if you have to battle with your tools the
> whole way. I guess you have to really be determined to implement
> a self-timed design in a Xilinx FPGA.
>
> --
>
> Phil
--
--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: 35704
hamish@cloud.net.au wrote:
> In my experience, you can't instantiate Xilinx macros in your
> HDL code. Ngdbuild doesn't know anything about them (only
> primitives).
>
You can, but the edif files for any macros you use have to be found by
ngdbuild.
--
--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: 35705
Hi -
Another approach is to XOR the outputs of the two shift registers.
If the desired output is 100110, then create two 6-bit shift registers
(we'll see why 3-bit registers won't work in just a moment). The
first register, clocked on the rising edge, is *synchronously*
initialized with the following contents:
MSB -> 1 1 1 0 0 0 <- LSB
The second register, clocked on the falling edge, is synchronously
initialized with:
MSB -> 0 1 0 1 0 1 <- LSB
The two MSBs are XORed to produce the output.
rising edge 1: reg 1 out = 1, reg 2 out = 0, XOR = 1
falling edge 1: reg 1 out = 1, reg 2 out = 1, XOR = 0
rising edge 2: reg 1 out = 1, reg 2 out = 1, XOR = 0
falling edge 2: reg 1 out = 1, reg 2 out = 0, XOR = 1
rising edge 3: reg 1 out = 1, reg 2 out = 0, XOR = 1
falling edge 3: reg 1 out = 1, reg 2 out = 1, XOR = 0
rising edge 4: reg 1 out = 0, reg 2 out = 1, XOR = 1
falling edge 4: reg 1 out = 0, reg 2 out = 0, XOR = 0
rising edge 5: reg 1 out = 0, reg 2 out = 0, XOR = 0
falling edge 5: reg 1 out = 0, reg 2 out = 1, XOR = 1
rising edge 6: reg 1 out = 0, reg 2 out = 1, XOR = 1
falling edge 6: reg 1 out = 0, reg 2 out = 0, XOR = 0
Since only one XOR input changes at a time, we get no glitches. (This
assumes that your XOR is glitchless for transitions on a single input,
which it will be if you build it with a Xilinx LUT or even a
straightforward sum of products structure. But I'm sure someone
possesses the technology to make a glitchy XOR.)
Note that the register patterns need 6 clocks to repeat, hence the
need for double-length registers.
Bob Perlman
Cambrian Design Works
On Fri, 12 Oct 2001 23:33:07 +0100, "Johan Ditmar"
<johan.ditmar@nospamceloxica.com> wrote:
>Hello there,
>
>The past few days I have been trying to come up with a way to describe a
>generic pulse generator in Verilog (or VHDL) using shift registers. What I
>would like it to do is to take an arbitrary pulsetrain as a parameter (for
>example "100110") and then generate this pulse train repeatedly from an
>incoming clock signal. However, each bit in the pulse train corresponds to
>half an incoming clockcycle! I came up with the following scheme to do this:
>
>I implement two rotating shift registers (A and B) of three bits wide, one
>that is sensitive to the positive clock edge and one on the negative. I
>initialise one with the even bits of the pulse train ("101") and one with
>the odd ("010") and I let them run on the incoming clock.
>
>Then I generate a signal from the incoming clock, which simply follows this
>clock (using two flip flops, one positive and one negative edge sensitive),
>and I use this signal to either choose the output of shift register A or
>shift register B and this is then the output of the whole circuit.
>
>However, the output of this circuit is going to be used as a clock which
>feeds other circuits, so it should be glitch free. This is not always the
>case in my present design (I think). Is there some way to make my design
>glitch free? As the output changes on both positive and negative clock edge,
>I canīt put a simple register on the output :-( And I prefer not to use
>PLLīs or DLLīs (which may be used to generate the double clock frequency to
>make everything sensitive to the positive clock edge only).
>
>Any help is greatly appreciated!
>
>Regards,
>
>Johan Ditmar
>
>
Article: 35706Ras Sim <simsek@rhrk.uni-kl.de> wrote: : Hi folks! : I'm a student and i need a free PCI-Core wich is written in vhdl. : Where could I download it ? Not a free HVDL PCI-Core, but a free FPGA with a PCI Interface: Look at Quicklogics WebAsic Program and there PCI Series. Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 35707
"Eric" <erv_NOS_PAM@sympatico.ca> wrote > Tim wrote: > > > I disagree on the dual-use of pins. > > Could you explain why you disagree ? > What kind of problem would it create for your app ? Banking. With fast I/Os you pretty much have to take a strategic view when you allocate the I/Os, and thus the bank standards. If some of the banks (two for Virtex-II) are restricted to 3.3V, or whatever, this sure limits your options and/or complicates your work. I don't want to go overboard on this. Most of the config pins are used 'input-only', but Busy/Dout is OD/output and Init is OD. SelectMAP readback uses D0..7 bidirectionally. The official line is that VCCO should be flipped to 3.3V for all output-mode configuration pins, though probably the transistors would not tell anyone if we disobeyed, provided we made sure that the receivers were compatible. (The Virtex-II data book spells this out in more detail.) Usual form when bringing up a new board is to decide that the darned thing is _never_ going to configure. Anything to remove an engineering doubt... <snip> > Maybe all the pins that are already dual use would do better if they were > grouped on a single or a separate bank. However, I don't see where the > problem is for you since you seem to to configuration through JTAG and > you don't use these pin's alternate function. Nope. I have never tried JTAG. My usual practice is to arrange the card so that I can do an initial bring-up in slave-serial mode - cannot beat looking at the stream on DOUT :) Usually that is that, but sometimes the client wants to move to the faster SelectMap. So far, nobody has asked for JTAG config. But our work is probably not representative of civilized usage. > > Maybe the long term plan is to configure/readback the big stuff > > via JTAG only - > > It's not because you don't use other configuration methods that they're > useless. Yep, I guess I wasn't too clear. Here is the problem: Current (!) V-II parts need up to 32Mbits of config data. Click forwards a few generations and we are going North from 1Gbit. Handling this at speed cannot readily be done by extrapolating from JTAG, essentially a system designed by IBM in 1975. But it is also relatively difficult in system terms with SelectMap and its friends. I was speculating that the configuration interface will evolve to 'JTAG', if that is fast enough for you, plus 'NewTAG'. NewTAG will be a fast/smart serial link, possibly serviced at the other end by a boring old Virtex-II. Now all I need is for someone with his/her finger on the pulse to tell me that this is all being considered by IEEE Working Group 666 :)Article: 35708
From a FPGA User Perspective, How does Altera PLL differ from Xilinx DLL?Article: 35710
Altera will begin supporting the Linux operating system next year. Jim Schwalbe Sr. Field Apps Eng Altera Corp. jschwalb@altera.com "Rene Tschaggelar" <tschaggelar@dplanet.ch> wrote in message news:3BBC6DAA.B11075E6@dplanet.ch... > When I look at the rather complicated procedure concerning > MaxPlus2 of Altera, which only runs 3 month, I doubt it. > The commercial version requires a dongle. > > Rene > -- > Ing.Buero R.Tschaggelar - http://www.ibrtses.com > > Zoltan Kocsi wrote: > > > > I was away for a while from the NG, is there any word on FPGA > > vendors offering (or planning to) Linux toolchains (in the same > > config and pricing as their Win tools) ? > > > > Thanks, > > > > Zoltan > > > > -- > > +------------------------------------------------------------------+ > > | ** To reach me write to zoltan in the domain of bendor com au ** | > > +--------------------------------+---------------------------------+ > > | Zoltan Kocsi | I don't believe in miracles | > > | Bendor Research Pty. Ltd. | but I rely on them. | > > +--------------------------------+---------------------------------+Article: 35711
The PLL in the ALTERA ICs is a (P)hase locked loop, which uses a VCO to generate the output signal. A PLL can do clock rate conversion with (almost) any arbitrary conversion factor, where the DLL (D)elay locked loop in the Xilinx devices can only divide by 1.5,2,2.5,3,4,5,8,16 and double the input frequency. But the most important use of a DLL is deskewing of clock signals. This can also be done with PLLs (in the Altera parts) There are some "comparisons" papers from both companys which are trying to proofe the advantages DLLs/PLLs. I dont know at all, how realistic these measurements are and how much marketing-science is involved ;-) Regards FalkArticle: 35712
Leo Breuss <lbreuss-nospam@scs.ch> wrote in message
news:3BC6EB89.D6322711@scs.ch...
> Thank you, Fred.
>
> There is a thing I have to add. In case1, in my VHDL code it says
> Clk2 <= not Clk1; -- period 8 ns, duty cycle 50%
> So the tools do know exactly about the relation of Clk2 and Clk1. They
> will know, that from rising edge Clk1 to rising edge Clk2 there are only
> 4 ns (positive duty cycle of Clk1)! This will very likely generate
> errors, when the tools are not able to satisfy a path delay Reg1_out to
> Reg3_in of less than 4 ns.
>
> How do I specify constraints for the tools or guide the tools to avoid
> Reg3_in changing state in the setup/hold window of Reg3 or violating its
> setup/hold time? Is there a MINDELAY constraint, if I accept that
> Reg1_out arrives at Reg3_in shortly after rising edge of Clk2?
>
Sorry Leo, I did not see your clk edge defifnition.
IIRC, conventional constraints apply rising to rising edge (and so will also
meet falling to falling) but not guarantee rise to fall or fall to rise. To
do this create a time group rising and a time group falling using the
syntax:
TIMEGRP RFFS = RISING FFS ("*"); // creates a rising group called RFFS
TIMEGRP FFFS = FALLING FFS ("*"); // creates a falling group called FFFS
(these are a global assignment to all flip flops)
then constrain using:
TIMESPEC TS_fall_2_rise = FROM : FFFS : TO : RFFS : 4 ns ;
Beware though, because although I have used this sucessfully in the past,
when I used it again recently, the log file reported that there were no nets
in the group - strange. I worked round it rather than spend time checking it
out.
This info is direct from the sample user constraints file which is created
when ever a foundation project is created - it has extensive examples of
this type - it should exist in you roject directory and be called
<projectname>.ucf
Although I think this answers your question, I have doubts about your
implementation in this case. 125MHz (8ns) is fast enough without opposite
edging the clock. Also I have guessed that your clk1 is being multiplexed
somewhere which will result in clock skew which is not accounted for by the
above constraint scheme. Maybe it would be better to treat even the the
inverse clock as a totally asynchrous one and synchronise the enable to the
clk2 domain before applying it to the mux chain using 2 regs as per Mikes
suggestion. This will mean, of course that you will not have cycle by cycle
muxing capability but I don't think the original could reliably perform that
task either.
Regards,
Fred
ps: More at http://support.xilinx.com - Advanced Search untick answers
database (only) keywords: constraints and timing and UCF
Article: 35713<hamish@cloud.net.au> wrote in message news:B2by7.1874$bE1.12165@news1.rdc1.nsw.optushome.com.au... > Tim <tim@rockylogic.com.nospam.com> wrote: > > I guess. For the XC2V10000 the times work out as > > JTAG 1000ms (33MHz, 1-bit) > > Slave Serial 500ms (66MHz, 1-bit) > > SelectMap 60ms (66MHz, 8-bit) The JTAG rate of 1 sec for 10000 gates seems okay, but the devices are rated to operate at 10M. Perhaps they could improve (why is it so slow?)Article: 35714
Hi, Wondering if anyone can give me any tips on improving my timing. I am reading in 4 bit data into IFD's (inputs and outputs are registered, Pad to Setup = 2ns). This is accumulated, after passing through a number of things, and outputted as a 20bit number. (goes from a registered latch, to OFDs to output pads). My problem is that before I included the 20bit output, I had a 6bit test output with Clock to Pad constraint of 3.4ns, which the PAR achieved quite easily. I then included the 20bit, again with the Clock to Pad constraint of 3.4ns, and the PAR can neither achieve this for both the 20bit output and the 6bit test output, with net delays of 5ns. Is there anyway to improve this? Why the degradation of the 6bit output? The design runs at 32MHz on a Spartan II. thanks adrianArticle: 35715
"Andrew Brown" <andrewbr@nortelnetworks.com> wrote > > > > For the XC2V10000 the times work out as > > > JTAG 1000ms (33MHz, 1-bit) > > > Slave Serial 500ms (66MHz, 1-bit) > > > SelectMap 60ms (66MHz, 8-bit) > > > The JTAG rate of 1 sec for 10000 gates seems okay, but the devices are rated > to operate at 10M. > Perhaps they could improve (why is it so slow?) XC2V10000 is 10M (marketing) gates with 32M config bits. At 33MHz this takes approx 1 second. So slow because 33MHz is slow. But it is only a few years since 33MHz was rather fast :)Article: 35716
Hi All, I have two Spartan2 on my board with their respective DONE pin tied together, pulled-up and connected to a LED. The LED is supposed to light up when both of the FPGA are configured. During testing phase, the 2 FPGAs are configured using JTAG. Both of them configured, LED lights, and work just fine. However, here's the problem when I am trying to move away from the JTAG cable: When I was configuring the 2 with JTAG, even after the first (FPGA1) is configured, JTAG programmer complains it can't verify DONE goes high. Sure enough, DONE is still "low", because my 2nd FPGA is not configured. But the real problem is FPGA1 does not start running until *AFTER* FPGA2 is configured and releases its DONE pin. So here is my question: (1) does anyone know if a Spartan2 sample the value of its DONE pin before it starts functioning (startup sequence)? (2) If so, is there a way I can get away with it? (some setting in the bitstream maybe?) From Xilinx datasheet, it mentioned how one can do a "Synch-to-DONE" startup. That is great but what I want is EXACTLY the opposite. I want FPGA1 to be up and running *before* FPGA2 starts. And sure enough, my bitstream used just the default startup sequence with no event depends on DONE. I can't figure out why would FPGA1 waits for the DONE pin to goes high. The configuration flowchart in Xilinx datasheet didn't mention sampling of DONE at the end... Any help would be greatly appreciated. Hayden SoArticle: 35717
Noddy wrote: > Hi, > > Wondering if anyone can give me any tips on improving my timing. I am > reading in 4 bit data into IFD's (inputs and outputs are registered, Pad to > Setup = 2ns). This is accumulated, after passing through a number of things, > and outputted as a 20bit number. (goes from a registered latch, to OFDs to > output pads). My problem is that before I included the 20bit output, I had a > 6bit test output with Clock to Pad constraint of 3.4ns, which the PAR > achieved quite easily. I then included the 20bit, again with the Clock to > Pad constraint of 3.4ns, and the PAR can neither achieve this for both the > 20bit output and the 6bit test output, with net delays of 5ns. Is there > anyway to improve this? Why the degradation of the 6bit output? The design > runs at 32MHz on a Spartan II. > > thanks > adrian It sounds like in the first case the output FFs were being mapped into the IOBs but when you added the 20-bit output they weren't. Could you be in the situation now where both the test output and the LS 6 bits of the real output are being driven from the same FFs ? i.e. a victim of over-enthusiastic optimisation by the synth/P&R tool(s).Article: 35718
Hi, open the compiler and go to "Interfaces", "EDIF Netlist Reader Settings". For the vendor choose Mentor Graphics or Leonardo Spectrum. You may also want check the customize button. Best Regards Wolfgang http://www.elca.de "Huang Qiang" <jameshq@liv.ac.uk> schrieb im Newsbeitrag news:9q6jgn$t79$1@news.liv.ac.uk... > Hi all: > I have tried to compile the VHDL file in Leonardo spectrum and generate > a *.edf file and import into the Altera maxplus II and compile it create a > default symbol. every step worked without problem. But when I use the symbol > in the graphic design and try to compile it I encounter the following > problem: > > Warning " I/O error can't open file *.lmf " > Error "Can't find design file 'dffe' " > > I can't find any setting the *.lmf (library mapping) setting in Altera > MaxPlus II (PC version). > Could anybody help me? Thank you very much! > > best regards! > > email: jameshq@liv.ac.uk > >Article: 35719
Brian Davis wrote: > Andy Peters <andy@exponentmedia.deletethis.com> wrote: > >>Uh oh! The person who posted Synplify's results for that 56-bit counter >>problem is in line for an ass-whooping! >> >>-a >> > > Andy, > > They haven't remotely detonated my key ( or my ass ) yet :) > > According to the Synplify license ( excerpt copyright Synplicity ): > > "Licensee acknowledges that the scope of the licenses granted > hereunder do not permit Licensee (and Licensee shall not allow > any third party) to:" > <snip> > "(iv) disclose the results of any benchmarking of the SOFTWARE, > or use such results for its own competing software development > activities, without the prior written permission of Synplicity;" > > Personally, I wouldn't consider answering a question on how to make > a counter synthesize better to be a "benchmark"... We don't consider it to be a "benchmark" either. > > But then again, nor would I make the software guys writing the > synthesis tool insert a copyright message into any cuts and pastes > done from the online help code examples... I think someone just set the "Copyright" field during the help file build not knowing what it did. I'll forward this to our documentation folks. > > Brian > > p.s. : upon further reflection, perhaps I should have checked to see if > posting an excerpt of the license terms is a violation of the license... >Article: 35720
Is there any good JTAG-Programmer that I can use under Linux to program Xilinx FPGAs and PROMs over the Parallel III Cable? I thought the Xilinx JTAG-Programmer is free, but I didn't find a place to download it in a linux version. Any good ideas? Regards MarcArticle: 35721
Brian Davis wrote: > From the Webpack XST license ( excerpt copyright Xilinx ): > > "2. Restrictions." > <snip> > "You may not publish any data or information that compares > the performance of the Software with software created or > distributed by others." > > > ( Had I posted both license excerpts in the same message, would > that constitute 'license benchmarking' ? ) > > ---------------------------------------------------------------- > > >>Uh oh! The person who posted Synplify's results for that 56-bit >>counter problem is in line for an ass-whooping! >> > > Upon even more reflection, should it come to that, I could > probably plead insanity vis-a-vis my original counter post: > > JUDGE: How do you explain this egregious posting of useful > information? > > DEFENDANT: But your Honor, after reading 3000 responses about > asynchronous resets and GSR, none of which clarified the cause > of the coherently cleared counter curiously containing copious > CLBs, I just HAD to post a message explaining the paradoxical > result that lowering the synthesis target frequency would result > in a counter that is both smaller and faster after P&R. If the load control and data for a sync load are less critical (before P&R) than other input signals to the counter, then we build them into the carry chain luts. Otherwise, they get their own column following the carry chain. Synplify should have used the sync reset instead of building a sync load. > > JUDGE: For your offense, and in the light of your excessive > alliteration of words beginning with the letter "C", I hereby > sentence you to use FPGA Express for all future synthesis work. > Bailiff, take him away. > > > Brian >Article: 35722
Hi, Tim wrote: > "Eric" <erv_NOS_PAM@sympatico.ca> wrote > > > Tim wrote: > > > > > I disagree on the dual-use of pins. > > > > Could you explain why you disagree ? > > What kind of problem would it create for your app ? > > Banking. With fast I/Os you pretty much have to take a strategic > view when you allocate the I/Os, and thus the bank standards. If some > of the banks (two for Virtex-II) are restricted to 3.3V, or whatever, > this sure limits your options and/or complicates your work. > If I get you well, when configuring in bit serial, the annoyance is that D0, Dout and Init_B being part of Bank 4, they force you to use 3.3V on the other IOs of that bank. Using SelectMap does the same for bank 5 (if you don't use SelectMap, bank 5 is unrestricted). A better way would be to have a specific bank that contains all dual use pins that are mandatory for all configuration modes (D0, Dout, Prog_B, Init_B, Done, M0..2, HSwap_En, TCK, TDI, TDO, TMS). As they are now, except D0 and Dout, they can't be used as IO at all. Allowing dual use and placing them in a common (voltage restricted if needed) bank would free Bank 4 in all apps, and provide up to 11 additional IOs in the same package. CS_B, RdWr_B, D1..D7 being optional, they can be put in another bank where their dual use nature would go undetected when SelectMap is not used. Same would be true for configuration address pins A0 .. An, should they be added as an option. > <snip> > > > > Maybe the long term plan is to configure/readback the big stuff > > > via JTAG only - > > > > It's not because you don't use other configuration methods that they're > > useless. > > Yep, I guess I wasn't too clear. Here is the problem: Current (!) V-II > parts need up to 32Mbits of config data. Click forwards a few generations > and we are going North from 1Gbit. Handling this at speed cannot readily > be done by extrapolating from JTAG, essentially a system designed by IBM > in 1975. But it is also relatively difficult in system terms with > SelectMap and its friends. > > I was speculating that the configuration interface will evolve to 'JTAG', > if that is fast enough for you, plus 'NewTAG'. NewTAG will be a fast/smart > serial link, possibly serviced at the other end by a boring old Virtex-II. > Sure, 33 Mhz JTAG is slow for 32 MB devices and won't cut it for future 1Gb+ FPGAs, but then a speed doubled & DDR version of SelectMap (133 Mhz x 2 ) would configure a hypothetical 1Gbit FPGA in less than 500 ms. Not that bad ! Very high speed serial could also be added whenever it will be needed, my point was that the more config modes you have, the easiest it's to integrate a FPGA in a broad range of devices and having as many dual use pins as possible reduces the number of pins that are useless (or not used by some) once the device is configured. Granted, these are not too important for high end devices that cost 4000+$ and come in FF1517 package, but at the low end (where the volume applications are) these details really make a difference. At all times, care should be taken so that whenever a mode is not used, it does not interfere with user IO usage. > > Now all I need is for someone with his/her finger on the pulse to tell me > that this is all being considered by IEEE Working Group 666 :) When there's a will, there's a way ... regards, Eric.Article: 35723
Thank you, Fred.
> TIMEGRP RFFS = RISING FFS ("*"); // creates a rising group called RFFS
> TIMEGRP FFFS = FALLING FFS ("*"); // creates a falling group called FFFS
> (these are a global assignment to all flip flops)
> then constrain using:
> TIMESPEC TS_fall_2_rise = FROM : FFFS : TO : RFFS : 4 ns ;
But: the path from Reg1 to Reg3 has even more delay than 4 ns. It should be
allowed to take 8ns.
I think your solution works.
I have to try an even more elegant and precise idea:
TIMESPEC "TS_Sel_path" = FROM FFS(Reg1*) 8.000;
this sets on all pathes originating at FFs Reg1* a TIMESPEC of 8 ns.
Do you think this could work? (I do not care if setup/hold of Reg3 is violated)
> Although I think this answers your question, I have doubts about your
> implementation in this case. 125MHz (8ns) is fast enough without opposite
> edging the clock.
(The schematic I have shown is only the falling edge path of data and an
independent block generating the Select signal. There is also a rising edge data
path (inverted Clk2), which is served by the same Select signal MUX_Sel from
Reg1 (not drawn). The clocks Clk1 and Clk2 are not necessarily synchronous, but
if they are, then it is Clk2 <= not Clk1 for the schematic.)
> Maybe it would be better to treat even the the
> inverse clock as a totally asynchrous one and synchronise the enable to the
> clk2 domain before applying it to the mux chain using 2 regs as per Mikes
> suggestion.
You're right. If only I had enough ressources in the FPGA... But the question
for timing constraints would be the same. The problem is just shifted in front
of the synchronizing FFs.
Best regards,
Leo
Article: 35724Marc Reinert <reinert@tu-harburg.de> wrote: > Is there any good JTAG-Programmer that I can use under Linux to program > Xilinx FPGAs and PROMs over the Parallel III Cable? > I thought the Xilinx JTAG-Programmer is free, but I didn't find a place > to download it in a linux version. > Any good ideas? > Regards > Marc try this: http://www.cse.cuhk.edu.hk/~khtsoi/project/Xilinux/ regards, stefano
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