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
stephen.busch@web.de (stephen) wrote in message news:<6643d19f.0210300556.2952775b@posting.google.com>... > Hi Gary > > garys@altera.com (Gary Sugita) wrote in message news:<a2058d2c.0210291941.371a89c7@posting.google.com>... > > Hi Stephen, > > > > Without seeing your .ESF file itself it is hard to definitely pinpoint > > the problem However, here are some questions and suggestions. > > > > > > 1) Have you tried to move the regions at all through TCL? You mention > > this later on in your posting (just changing the ll_origin assignment > > does NOT refresh the node locations. Currently this must be done > > through the GUI). Changing the LL_ORIGIN statement through TCL is an > > almost sure-fire way to break things. > > I noticed this. Here is a way I figured out to move LogicLock regions > from a Tcl script. > . Import the existing logicLock regions from .esf files > . For the ones you need to move : > . create a new region of the same size that the one you need > to move (fixed size) > . set the position of the new region (fixed position) > . use this region as a parent for the one you want to move. > This way the fitter moves the region to the right place and the cells > are inside. This method isn't very elegant but it works. > That's a creative way of doing it :) I agree this is not elegant, but there will be a TCL move command in Quartus 3.0. > > 2) Have you tried changing the LL_PARENT assignment through TCL? > > Changing the parent may require the region to be moved. The GUI knows > > how to handle this, but the TCL interface does not. As a result, some > > regions may not be within their parent region. This will also > > generate messages like the ones you are seeing. Again, do not change > > the LL_PARENT from TCL. > > Changing the LL_PARENT seems to work when I first import the region > and then change the assignment. I got the results I expected when I > opened the project from the gui. I guess it works because the regions > are converted to FLOATING and moved to the right place by the fitter. Yes, its only because the regions were floating did this work correctly. The fitter made the move. This won't work with fixed location regions. > > 3) It is always a good idea to have registered boundaries between > > modules. > > I did. > > > > Some things you can check to help you narrow down what is going wrong > > are: > > > > 1) Use the GUI to do the same steps that you are trying to do from > > TCL. Does it work there? (if it does, I would guess that your > > problems are related to number 1 or 2 above) Do the regions show up > > RED in the Logiclock Window after you import them? Or does everything > > look okay and you still get these error messages when compiling? (in > > this case I would say #3 above is part of your problem) > > > > 2) Use the GUI in the lower level to see if the regions are okay (ie > > all nodes are within the region boundaries) > > > > I followed your advice. It seems that things become difficult at the 3rd > level of imbrication. Some of the cells, but not all, are moved outside > lower level regions. They are still inside the parent region but not any more > in the child region. > So things start to break down on the third level, so that's the second import right? When you did the import, did you have the AB.esf AND the ABA.esf in the project directory of A? Were there any LL_IMPORT_FILE options in the A.esf file? Can you try this again with ONLY the AB.esf in the project directory of A (and using no LL_IMPORT_FILE options)? This may be a problem we are already aware of. > > > > On a side note, here are some comments about your methodology: > > > > You say that multiple people are working co-operatively on this > > design. I assume that you need the TCL script because people may > > change the placement of lower level modules and you want to have an > > automatic merge and update of the top-level design. > > Right. I also want them to be able to integrate their modifications > without my help. For exemple we have a person working on a memory > controller which interacts with the rest of the design. During the > debug phase he often changes his code. To recompile he only has to run the > makefile, without knowing to much about how quartus works. So he > could focus on his design. > Doing things on a makefile / script basis make it possible to reproduce > the same result on each resynthesis. Using the gui people often didn't > remember what they did and where unable to know why things worked yesterday > and not today. I agree that you will want to use a script based approach to integrating everything. But what I was proposing was that set things up using the GUI initially, and then use a script for everyone to do their merging easily. > > > I would recommend you go about doing this as follows: > > > > Do your initial merge using the GUI. Do your importing, moving, > > changing parents etc. all through the GUI the first time. Now that > > you have a "good" top level design where everything works and makes > > sense, you are are ready to use the TCL script to "update" any of the > > regions that need changing. > > > > Using the cmp logiclock_import 0 1 0 1 0 "region_name" > > Where region_name is the name of the region you want to update, and in > > your case you would run this command once for every region. This > > command preserves the placement of the region in the top level, and > > the LL_PARENT settings. > > > > With this flow, you can do all of your top-level floorplanning, and > > only update the contents of the regions. As an additional benefit, it > > also eliminates the need to try to move regions around using TCL, > > while only forcing you to use the GUI once. > > I changed I bit my aproach because I noticed that compilation times of > intermediate LogicLock level are very long. Here is an exemple : lets > say I have 3 regions AAA AAB AAC which should be grouped together into > region AA. There are almost no more LE than the ones contained in > AAA AAB AAC. So, as the position of almost every LE is known fitting of > AA should be very fast. This is not what happens. I guess the reason > it that quartus redoes the routing each time. As the result of the routing > couldn't be locked down things are redone at every level, right ? > > So now I only create the lowest level logic lock regions (AAA ...) > and I directly place them into the top level. This is much faster than > creating the regions AA and A first. This way the others problems also > disappear. > > Here is an other question. Is there a way to lock down the routing or is > it redone in every case. If for exemple only one (small) LogicLock region > changes is quartus redoing the hole routing ? Is there a way to only change > the content of a ROM without redoing a complete fit ? > Can you send me the archived project of the level at which you first saw problems when you imported? I want to try to recreate the error on my end. > Thank you very much for your help > > Stephen > > > > > Hope this helps. > > > > -Gary Sugita > > > > > > > > stephen.busch@web.de (stephen) wrote in message news:<6643d19f.0210240712.62595be2@posting.google.com>... > > > Hi, > > > I'm using the LogicLock design flow to incrementally place and route > > > a design on a APEX1500KE device. Several people work on the project > > > and I > > > need to automate the compilation flow, so everything is done with tcl > > > scripts. > > > > > > I followed the instructions from Altera but I still have some > > > problemes. The structure of the design is something like this : > > > top +-- A > > > | +--- AA > > > | +--- AB > > > | +---ABA > > > | +---ABB > > > +-- B > > > | +--- BA > > > | +--- BB > > > | +---BBA > > > | +---BBB > > > > > > Here is what I do : > > > . I generate a edf file for each module (AA, BA, ABA, ABB, BBA, BBB) > > > with Leonardo. > > > . I run quartus for each submodule (AA, BA, ABA, ABB, BBA, BBB) to > > > generate the esf and vqm files. Each submodule contains one or > > > more > > > LogicLock regions. > > > . to generate the esf and vqm file of bloc AB I use the vqm and esf > > > files > > > generated for ABA and ABB plus an additional edf file. To enforce > > > the > > > hierarchie I use the LL_PARENT assignment. I change this > > > assignment > > > after importing the lower level .esf files, otherwise it doesn't > > > work. > > > ... > > > . for the final place and route I use the files A.vqm A.esf B.vqm > > > B.esf and > > > top.edf. The LogicLock regions defined are visible and have the > > > correct > > > size at the top level. The position is chosen automaticly by > > > quartus > > > for the moment. > > > > > > For the lower levels everything is fine but I get some problems at the > > > top > > > level. I get a lot of messages like the one : > > > Warning: Ignored back-annotated location assignment on node > > > bmicro:bmicro_inst|i2c:i2c_enabled_i2c_inst|i2c_intermediaire:i2c_intermediaire_inst|i2c_reste:reste|modgen_eq_445_ix46~I_I > > > assigned to LogicLock region > > > i2c_i2c:i2c_enabled_i2c_inst_bmicro:bmicro_inst because location is > > > outside region boundaries > > > How could this happen ? At the lower levels all the cells where inside > > > the > > > logiclock region and I didn't get the message. For the moment I didn't > > > try > > > to move manually the regions. > > > > > > Quartus also complains about carry chains it couldn't place inside a > > > low level > > > logiclock region. But I didn't get this message when it fitted this > > > region or > > > the next higher level. > > > > > > My next problem is that I need to chose the position of the logiclock > > > regions > > > because of timing issues. I can do this using the quartus gui but I > > > want to > > > move them from a tcl script. When I only change the LL_ORIGIN > > > assignment > > > the LL_LOCATION assignments aren't updated. Does anyone know which > > > command > > > I need to run ? > > > > > > thanks for you help > > > stephenArticle: 49101
It is CMOS, but there also "linear" sense amplifiers, like they are in all CPLDs except CoolRunner (which is all-CMOS = very low power) Peter Alfke, Xilinx =================== Pierre Lafrance wrote: > Hi all > One of my friend, who study electrical eng at university, ask me what > kind of technology is used to implement a 9500, meaning is it a > BI-CMOS, ACT, TTL, etc... This is for a lab he as to do. > I was not able to find this information on Xilinx web site. > > Cheers !Article: 49102
Jim Granville wrote: > Hmmm - I think even this needs qualification.. :) > > Master-Slave implies/requires a hand-over, or make-before-break action. yes, agreed > In an extreme slow edge case, the threshold skews could cause > make-before-break to become break-before-make, so I don't agree > "You can have any rise or fall time you want" - > > 'Properly designed' cannot eliminate threshold variations, due > to process shifts, as well as practical things like local gound/vcc > movement. I disagree. We are talking about a single flip-flop with a common ground. The designer makes sure that there is no overlap. Otherwise it is not a "well-designed" flip-flop. > A minimum slew rate is giving you three things > > - sufficently narrow time skew across multiple registers yes, agreed > - sufficently narrow time skew within the master-slave core I call that well-defined set-up and hold times > > - Improves noise margin, as Q driven bounce in CMOS shifts the > threshold ( == your double clocking case, which can also include > miss-clocking ) This is whereI disagree, and this is the reason for continuing this pedantic thread: A flip-flop can NEVER miss a clock. There is NO way to sneak the clock from one level to the other, without the flip-flop recognizing it. That's always my argument when users complain that a counter bit does not toggle. It cannot avoid toggling, but it might have toggled twice, which looks deceptively like no toggle... Peter Alfke, Xilinx ApplicationsArticle: 49103
--------------CB07FD41E3C39322A1341284 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit I am happy to report that the results of our metastabity tests are now posted at http://support.xilinx.com/support/techxclusives/metas-techX32.htm The capture window causing 500 ps of metastable delay is an incredibly small 0.03 femtoseconds. If the clock rate is below 300 MHz and the routing delay is minimal, then the MTBF will be thousands or even millions of years. Good to know! Peter Alfke, Xilinx ApplicationsArticle: 49104
Hello Peter, - interesting debate.. Peter Alfke wrote: > > Jim Granville wrote: > > > Hmmm - I think even this needs qualification.. :) > > > > Master-Slave implies/requires a hand-over, or make-before-break action. > > yes, agreed > > > In an extreme slow edge case, the threshold skews could cause > > make-before-break to become break-before-make, so I don't agree > > "You can have any rise or fall time you want" - > > > > 'Properly designed' cannot eliminate threshold variations, due > > to process shifts, as well as practical things like local gound/vcc > > movement. > > I disagree. We are talking about a single flip-flop with a common ground. The > designer makes sure that there is no overlap. Otherwise it is not a > "well-designed" flip-flop. but a single flip-flop is of no practical use, so identifying the real-world effects that can move the threshold becomes important. They are external to the FF, so 'well designed' is not really a factor. > > > A minimum slew rate is giving you three things > > > > - sufficently narrow time skew across multiple registers > > yes, agreed > > > - sufficently narrow time skew within the master-slave core > > I call that well-defined set-up and hold times > > > > > - Improves noise margin, as Q driven bounce in CMOS shifts the > > threshold ( == your double clocking case, which can also include > > miss-clocking ) > > This is whereI disagree, and this is the reason for continuing this pedantic > thread: > A flip-flop can NEVER miss a clock. There is NO way to sneak the clock from one > level to the other, without the flip-flop recognizing it. Not even if the make-before-break action needed, has morphed into break-before-make ? Modern FF's seem to mostly use transmission gates, and in the extreme case ( _very_ slow slews ) these would be all-on, and master-slave ceases to exist. In this case, it must be very close to metastable in nature, with the final state a lottery. I suppose one could claim that it recognized the clock in going unstable :) but the nett user symptom is it missed the clock. Or, one could claim that in going to 50%, then changing its mind and not actually toggling, it doubled clocked :) To me, once the master-slave hand-over fails, it is no longer a true Flip-Flop, but a Might-Flop ! :) > That's always my argument when users complain that a counter bit does not > toggle. It cannot avoid toggling, but it might have toggled twice, which looks > deceptively like no toggle... I'll agree double-toggling is by far the dominant failure mode, but I'm not sure I'm brave enough to claim miss-clock NEVER occurs. I have seen some very strange effects from logic under the 'stress' of outside spec signals - so much that I'm amazed Schmitt clocks are not mandatory. Jim G.Article: 49105
Has anyone seen any instances of the image programmed in a Xilinx XC18VXX device getting corrupted? I've seen this several times on both XC18V02 and XC18V04 devices. We load an image in the PROM once and don't touch it again. The FPGA gets successfully configured by the PROM numerous times until one day configuration fails. Once it fails, the only way to get things working again is to reprogram the PROM. Anyone else seen anything like this??Article: 49106
skyhawk172L@attbi.com wrote: > > Has anyone seen any instances of the image programmed in a Xilinx > XC18VXX device getting corrupted? > > I've seen this several times on both XC18V02 and XC18V04 devices. We > load an image in the PROM once and don't touch it again. The FPGA gets > successfully configured by the PROM numerous times until one day > configuration fails. Once it fails, the only way to get things working > again is to reprogram the PROM. > > Anyone else seen anything like this?? Next time it occurs, read the PROM, and check the details of the failure(s). ( 0->1 or 1->0, Bit/Byte/Row etc ) Does raise an intersting question about ECC in Loader devices ? -jgArticle: 49107
On Fri, 01 Nov 2002 15:25:46 +1300, Jim Granville <jim.granville@designtools.co.nz> wrote: >skyhawk172L@attbi.com wrote: >> >> Has anyone seen any instances of the image programmed in a Xilinx >> XC18VXX device getting corrupted? >> >> I've seen this several times on both XC18V02 and XC18V04 devices. We >> load an image in the PROM once and don't touch it again. The FPGA gets >> successfully configured by the PROM numerous times until one day >> configuration fails. Once it fails, the only way to get things working >> again is to reprogram the PROM. >> >> Anyone else seen anything like this?? > > Next time it occurs, read the PROM, and check the details of the >failure(s). ( 0->1 or 1->0, Bit/Byte/Row etc ) > > Does raise an intersting question about ECC in Loader devices ? > >-jg What, specifically, should I be looking for? I had one fail today and did a 'verify'. It came back and told me there was a mismatch at a certain location in the PROM. I can also do a 'readback' from the PROM and see what's in there. I can see differences. Now what??Article: 49108
Ken McElvain <ken@synplicity.com> writes: > There never was a 4.x version of Synplify, we skipped from 3.x to 5.x > because of beliefs in Asia about the number 4. I wrote: > Don't customers in Asia worry that when they buy version five of your > product, it's really version four? Peter Alfke <peter@xilinx.com> writes: > How many European and American hotels have a thirteenth floor, or a room > number 13? Not many. Same reason. And don't superstitious people then worry if they get room 1401 (US) or 1201 (Europe)? I've noticed that some passenger aircraft don't have a row 13. Anything I have control over will not have different numbers to avoid 4, 13, 666, or any other "unlucky" number, unless I have a customer that is otherwise going to refuse to sign a contract for a large amount of money.Article: 49109
This is a multi-part message in MIME format. ------=_NextPart_000_0021_01C28116.8A3507B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Peter, How in the HELL were you able to control the phase of a clock with (less = than) 0.03 fs resolution? Does this mean that the DCM's in your new Virtex-III's will have = femtosecond phase-shifter adjustability? Jitter in the = milli-femtoseconds (unit name?) ? Routing delays too low to publish? ;-D Bob "Peter Alfke" <peter@xilinx.com> wrote in message = news:3DC1D346.E1135A16@xilinx.com... I am happy to report that the results of our metastabity tests are now = posted at http://support.xilinx.com/support/techxclusives/metas-techX32.htm The capture window causing 500 ps of metastable delay is an incredibly = small 0.03 femtoseconds. If the clock rate is below 300 MHz and the = routing delay is minimal, then the MTBF will be thousands or even = millions of years. Good to know! Peter Alfke, Xilinx ApplicationsArticle: 49110
On Thu, 31 Oct 2002 14:14:12 -0800, John Larkin <jjlarkin@highSNIPlandTHIStechPLEASEnology.com> wrote: >On 30 Oct 2002 14:40:07 -0800, joefrese@hotmail.com (Joe Frese) wrote: > >>First off, thanks to all who responded to my last post, re: FPGA >>fullness. Your comments and suggestions were incredibly helpful. >> >>We recently purchased Active-HDL 5.1XE, and in experimenting with it, >>I discovered an FPGA design that does not simulate (post >>place-and-route) correctly . . . which is strange, as the design has >>been tested and verified as operating correctly in actual hardware. >>Digging a little deeper, I was able to identify a number of constructs >>in the design that cause problems in simulation, but should NOT cause >>problems in real hardware. >> >>Now, I could fix these areas so that the design simulates correctly, >>but the problem constructs are sprinkled heavily throughout, so to do >>so would be no small undertaking. My question is, therefore: how >>important is it to have a completely clean simulation? Is it >>important enough to renovate a working and tested design? Thanks in >>advance for your input. >> >>Joe Frese > > >I've done some pretty hairy stuff (77 MHz OC-3 data, microengines, >nasty state machines prowling multiport ram) without simulation, and >without a lot of trouble bringing them up. Just a timing report tells >us that the p&r looks OK. > >After all, simulation just tells you that you made a mistake, and >ultimately it becomes obvious, so why not just inspect the design >carefully before you compile it? This methodology only works for small, simple designs. The project I'm working on at the moment has about 1/2 million lines of source. Yes, we look over it carefully, but simulation is vitally important for a successful end result. Regards, Allan.Article: 49111
Hi frends! Welcomm to www.crackshop.org Small prices, good pricess. Hot DogArticle: 49112
skyhawk172L@attbi.com wrote: > > On Fri, 01 Nov 2002 15:25:46 +1300, Jim Granville > <jim.granville@designtools.co.nz> wrote: > > >skyhawk172L@attbi.com wrote: > >> > >> Has anyone seen any instances of the image programmed in a Xilinx > >> XC18VXX device getting corrupted? > >> > >> I've seen this several times on both XC18V02 and XC18V04 devices. We > >> load an image in the PROM once and don't touch it again. The FPGA gets > >> successfully configured by the PROM numerous times until one day > >> configuration fails. Once it fails, the only way to get things working > >> again is to reprogram the PROM. > >> > >> Anyone else seen anything like this?? > > > > Next time it occurs, read the PROM, and check the details of the > >failure(s). ( 0->1 or 1->0, Bit/Byte/Row etc ) > > > > Does raise an intersting question about ECC in Loader devices ? > > > >-jg > > What, specifically, should I be looking for? I had one fail today and > did a 'verify'. It came back and told me there was a mismatch at a > certain location in the PROM. > > I can also do a 'readback' from the PROM and see what's in there. I > can see differences. Now what?? Readback a failed one to a file, and if that file is not identical in format to the loaded one, read a GOOD prom back as well ( easy way to get two comparable files :) Also, read a BLANK one, to check which polarity is blank. Then, run a file compare program to compare both files, and check the differences report. Page-flipping in an editor can also show changes, once you know where to look. - jgArticle: 49113
"Peter Alfke" <peter@xilinx.com> wrote in message news:3DC1CF68.722D62F7@xilinx.com... > (snip regarding clock edge and master-slave flip-flops) > > This is whereI disagree, and this is the reason for continuing this pedantic > thread: > A flip-flop can NEVER miss a clock. There is NO way to sneak the clock from one > level to the other, without the flip-flop recognizing it. > That's always my argument when users complain that a counter bit does not > toggle. It cannot avoid toggling, but it might have toggled twice, which looks > deceptively like no toggle... > The one I remember being told not to do, though maybe it doesn't exactly apply here, has to do with reset on asynchronous counters. If you want an asynchronous BCD counter, you can set up an AND gate to reset the counter when it gets to B'1010'. It is possible that the such reset signal won't reset all the FF's before the reset signal goes away. In the case of edge triggered FF's, say for a falling edge, I would expect there to be a case where the clock wasn't high long enough before the falling edge. I seem to remember some circuit that I think Peter posted before containing two FF's where one times the signal for the other such that it can be guaranteed to have the right timing. I can't remember any more about it than that, though. -- glenArticle: 49114
"Bob" <nimby1_not_spmmm@earthlink.net> wrote in message news:bRmw9.372$t4.32691@newsread2.prod.itd.earthlink.net... Peter, How in the HELL were you able to control the phase of a clock with (less than) 0.03 fs resolution? Does this mean that the DCM's in your new Virtex-III's will have femtosecond phase-shifter adjustability? Jitter in the milli-femtoseconds (unit name?) ? Routing delays too low to publish? 1e-18 is atto. There are people who study how a chemical reaction happens between two atoms with attosecond range laser pulses. In 1as light travels 3A, about the diameter of an atom. -- glenArticle: 49115
On Fri, 01 Nov 2002 05:10:36 GMT, "glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote: > >"Bob" <nimby1_not_spmmm@earthlink.net> wrote in message >news:bRmw9.372$t4.32691@newsread2.prod.itd.earthlink.net... >Peter, > >How in the HELL were you able to control the phase of a clock with (less >than) 0.03 fs resolution? > >Does this mean that the DCM's in your new Virtex-III's will have femtosecond >phase-shifter adjustability? Jitter in the milli-femtoseconds (unit name?) ? >Routing delays too low to publish? No, no. It's all statistical. The clock and "data" are asynchronous, which means that, over time, all different phase alignments will be tested. If the clock period is (say) 3 ns, and 1 in every million "tests" produces an event, then the window size is 3 ns / 1e6 = 3 fs. Or something like that. Regards, Allan.Article: 49116
Georgi -
You hit the nail on the head. Thanks.
Bill
Georgi Beloev wrote:
>
> Bill,
>
> Have you simulated the powerup process of your CPLD design? To be more
> specific you have to include the following code in your testbench:
>
> reg PRLD;
> assign glbl.PRLD = PRLD;
>
> initial begin
> PRLD = 1;
> #100;
> PRLD = 0;
> end
>
> This tells the simulator that you are powering up the device and it
> will assign your power-up values to the signals. Otherwise they show
> as "X"s.
>
> Regards,
> -- Georgi
>
> Bill Turnip <BTurnip@wellspring.org> wrote in message news:<3DBE9D24.9206C4F@wellspring.org>...
> > SH7 -
> >
> > I did as you suggested, installing and overwriting a boatload of
> > files.
> > Alas, no positive results yet.
> > I slowed down the clock and selected a faster part as well. No
> > dice.
> >
> > Bill
> >
> > Spam Hater wrote:
> > >
> > > Bill,
> > >
> > > Did you install the ModelSim library updates? The ones that come in a
> > > zip file so there's no way to back them out?
> > >
> > > If so, that's your problem. I had to re-install ModelSim to get rid
> > > of them to fix the same problem.
> > >
> > > Dig into the waveform of the post-fit cpld, and you will see way too
> > > many X's on the signals.
> > >
> > > SH7
> > >
> > > On Sun, 27 Oct 2002 15:07:59 GMT, Bill Turnip <BTurnip@wellspring.org>
> > > wrote:
> > >
> > > >Hello group:
> > > > I'll try to keep this short. I have a simple asynchronous Verilog
> > > >module that takes 3 inputs to produce a few simple outputs.
> > > >Behavorially, the module works fine. I pumped the design through
> > > >WebPACK and targeted an FPGA as well as a CPLD. Behavorially, the
> > > >post-PAR and post-fit models simulate and match the behavorial model
> > > >(now with various delays, of course). To switch back and forth between
> > > >FPGA <> CPLD I simply changed the "properties" of the project, and
> > > >re-synthesized, etc. The verilog code for the module being implemented
> > > >as well as the testbench were the same for both the FPGA and CPLD
> > > >cases. I let the Xilinx IDE handle all the background stuff for the
> > > >ModelSim simulations of the post-PAR, post-Fit models.
> > > > So, I then made the design synchronous - added a clock as well as a
> > > >reset and made small modifications to the testbench - and repeated the
> > > >exercise above. The FPGA implementation works fine, with the behavorial
> > > >functionality matching the post-PAR (and post-map, post-translate, etc.)
> > > >functionality, now with delays of course. However, the post-fit CPLD
> > > >implementation does not work functionally at all! Again, I am using the
> > > >same testbench and verilog code for the two synchronous
> > > >implementations. It seems the post-Fit CPLD design is "stuck." The
> > > >outputs are correct for the first set of inputs passed to it from the
> > > >testbench, but after this they never change, as if time is not passing.
> > > >But the same exact code works for the FPGA! I'm new to this area, but
> > > >it doesn't seem to make sense. Do I need to do something special for
> > > >the clock or reset in the post-Fit code for the CPLD that is transparent
> > > >for the FPGA? I expected the CPLD implementation to be easier and less
> > > >complicated.
> > > > Thanks for any insight to this very interesting issue.
> > > >- BT
Article: 49117
Hi,
I'm trying to write some VHDL that will infer an FDRE (ff with clock
enable and *sychronous* reset) in a Xilinx Virtex-E or -2 device.
We've tried several versions of Synplify Pro 7.x, and they all waste a
LUT to implement the synchronous reset function.
The code used looks something like this:
foo : process (gsr, clk)
begin
if gsr = '1' then
ff <= '0';
elsif rising_edge(clk) then
if sync_reset = '1' then
ff <= '0';
elsif clk_enable = '1' then
ff <= other_sig;
end if;
end if;
end process foo;
Gsr can be traced back to the gsr input of a startup block.
Does anyone know how to do this without wasting a LUT?
TIA,
Allan.
Article: 49118
GEorgi -
I forgot to ask: why does my FPGA implementation work without this
(or
an equivalent) statement?
Bill
Bill Turnip wrote:
>
> Georgi -
>
> You hit the nail on the head. Thanks.
>
> Bill
>
> Georgi Beloev wrote:
> >
> > Bill,
> >
> > Have you simulated the powerup process of your CPLD design? To be more
> > specific you have to include the following code in your testbench:
> >
> > reg PRLD;
> > assign glbl.PRLD = PRLD;
> >
> > initial begin
> > PRLD = 1;
> > #100;
> > PRLD = 0;
> > end
> >
> > This tells the simulator that you are powering up the device and it
> > will assign your power-up values to the signals. Otherwise they show
> > as "X"s.
> >
> > Regards,
> > -- Georgi
> >
> > Bill Turnip <BTurnip@wellspring.org> wrote in message news:<3DBE9D24.9206C4F@wellspring.org>...
> > > SH7 -
> > >
> > > I did as you suggested, installing and overwriting a boatload of
> > > files.
> > > Alas, no positive results yet.
> > > I slowed down the clock and selected a faster part as well. No
> > > dice.
> > >
> > > Bill
> > >
> > > Spam Hater wrote:
> > > >
> > > > Bill,
> > > >
> > > > Did you install the ModelSim library updates? The ones that come in a
> > > > zip file so there's no way to back them out?
> > > >
> > > > If so, that's your problem. I had to re-install ModelSim to get rid
> > > > of them to fix the same problem.
> > > >
> > > > Dig into the waveform of the post-fit cpld, and you will see way too
> > > > many X's on the signals.
> > > >
> > > > SH7
> > > >
> > > > On Sun, 27 Oct 2002 15:07:59 GMT, Bill Turnip <BTurnip@wellspring.org>
> > > > wrote:
> > > >
> > > > >Hello group:
> > > > > I'll try to keep this short. I have a simple asynchronous Verilog
> > > > >module that takes 3 inputs to produce a few simple outputs.
> > > > >Behavorially, the module works fine. I pumped the design through
> > > > >WebPACK and targeted an FPGA as well as a CPLD. Behavorially, the
> > > > >post-PAR and post-fit models simulate and match the behavorial model
> > > > >(now with various delays, of course). To switch back and forth between
> > > > >FPGA <> CPLD I simply changed the "properties" of the project, and
> > > > >re-synthesized, etc. The verilog code for the module being implemented
> > > > >as well as the testbench were the same for both the FPGA and CPLD
> > > > >cases. I let the Xilinx IDE handle all the background stuff for the
> > > > >ModelSim simulations of the post-PAR, post-Fit models.
> > > > > So, I then made the design synchronous - added a clock as well as a
> > > > >reset and made small modifications to the testbench - and repeated the
> > > > >exercise above. The FPGA implementation works fine, with the behavorial
> > > > >functionality matching the post-PAR (and post-map, post-translate, etc.)
> > > > >functionality, now with delays of course. However, the post-fit CPLD
> > > > >implementation does not work functionally at all! Again, I am using the
> > > > >same testbench and verilog code for the two synchronous
> > > > >implementations. It seems the post-Fit CPLD design is "stuck." The
> > > > >outputs are correct for the first set of inputs passed to it from the
> > > > >testbench, but after this they never change, as if time is not passing.
> > > > >But the same exact code works for the FPGA! I'm new to this area, but
> > > > >it doesn't seem to make sense. Do I need to do something special for
> > > > >the clock or reset in the post-Fit code for the CPLD that is transparent
> > > > >for the FPGA? I expected the CPLD implementation to be easier and less
> > > > >complicated.
> > > > > Thanks for any insight to this very interesting issue.
> > > > >- BT
Article: 49119
Peng -
I don't understand; I have the same version of ModelSim and
I run 30 to 40 thousand lines of code. I get warned that I
have exceeded the starter version limit and that the "Simulation
run time might be quite adversely affected," but it still takes only
a few - OK, maybe several - seconds to run the simulation on my PIII
750MHz laptop.
Try an older version of Modelsim; I've heard the latest version
that comes with Webpack 5.1 will only run for 30 days, while the Webpack
4.3 version is not as restricted. Or so I've been told...
Bill
Colin Paul Gloster wrote:
>
> Peng Cong wrote:
> "Xilinx ISE 5.1 + Modelsim 5.5e
>
> When I use modelsim for simulation, it always propmt
> "Evaluation memory limit reached".
> How can I solve this problem?"
>
> Unfortunately this is a problem with the restricted
> version of Modelsim which Xilinx gives away for free.
> You can choose to:
> * not run your simulation in Modelsim;
> * make a smaller system to simulate, small enough to fit in the memory
> restrictions of Modelsim XE;
> or
> * buy a full copy of Modelsim.
Article: 49120Allan Herriman wrote: > > On Fri, 01 Nov 2002 05:10:36 GMT, "glen herrmannsfeldt" > <gah@ugcs.caltech.edu> wrote: > > > > >"Bob" <nimby1_not_spmmm@earthlink.net> wrote in message > >news:bRmw9.372$t4.32691@newsread2.prod.itd.earthlink.net... > >Peter, > > > >How in the HELL were you able to control the phase of a clock with (less > >than) 0.03 fs resolution? > > > >Does this mean that the DCM's in your new Virtex-III's will have femtosecond > >phase-shifter adjustability? Jitter in the milli-femtoseconds (unit name?) ? > >Routing delays too low to publish? > > No, no. It's all statistical. The clock and "data" are asynchronous, > which means that, over time, all different phase alignments will be > tested. Hopefully :) > > If the clock period is (say) 3 ns, and 1 in every million "tests" > produces an event, then the window size is 3 ns / 1e6 = 3 fs. Or > something like that. Light travels 9nm in .03fs, or appx 1/20 of the gate lengths of the FETS ( This excludes velocity factors, or electron wave effects ) Next task for Peter is to give a curve plot, of the Effective Aperture (in fs), against the Event Extension lifetime ( in ps ) :) We have one point : 500ps / 0.03fs Anyone care to calculate how many / how far electrons are involved in this ? ie how close are we to hitting a quantised limit, like Photomultipliers behave with photons ? Jim G.Article: 49121
> >How in the HELL were you able to control the phase of a clock with (less > >than) 0.03 fs resolution? > > > >Does this mean that the DCM's in your new Virtex-III's will have femtosecond > >phase-shifter adjustability? Jitter in the milli-femtoseconds (unit name?) ? > >Routing delays too low to publish? > > No, no. It's all statistical. The clock and "data" are asynchronous, > which means that, over time, all different phase alignments will be > tested. > > If the clock period is (say) 3 ns, and 1 in every million "tests" > produces an event, then the window size is 3 ns / 1e6 = 3 fs. Or > something like that. > Duh, is it possible to use the event occurances as some form of clock ?Article: 49122
Hi all, Does anybody has any reference schematics based on Altera's ARM Based Excalibur series of FPGAs.. SonuArticle: 49123
Hello, Every thing is possible, and retargetting FPGA to ASIC, or ASIC to FPGA is a common activitie for design centers. The main factors are technicals and financials : - A digital design, with very small limitations in term of gate number, memory size, use of IPs, macro blocks, frequency and so on (FPGA capabilities are, today, not so far from ASIC-pure digital- capabilities). Regards James -- James BEZAMAT bezamat.james@wanadoo.fr "alla" <alng23@hotmail.com> a écrit dans le message de news: aps669$cdd$1@tilde.itg.ti.com... > Just want see anyone here has any experience of converting a Xilinx FPGA > design into an ASIC implementation. If so, which vendor did you use? What's > the cost? Are you happy with the result? We are using the Virtex series and > considering this option. Thanks > >Article: 49124
"Allan Herriman" <allan_herriman.hates.spam@agilent.com> wrote in message news:3dc210cc.14049401@netnews.agilent.com... > Hi, > > I'm trying to write some VHDL that will infer an FDRE (ff with clock > enable and *sychronous* reset) in a Xilinx Virtex-E or -2 device. > > We've tried several versions of Synplify Pro 7.x, and they all waste a > LUT to implement the synchronous reset function. > > The code used looks something like this: > > foo : process (gsr, clk) > begin > if gsr = '1' then > ff <= '0'; > elsif rising_edge(clk) then > if sync_reset = '1' then > ff <= '0'; > elsif clk_enable = '1' then > ff <= other_sig; > end if; > end if; > end process foo; > > Gsr can be traced back to the gsr input of a startup block. > > Does anyone know how to do this without wasting a LUT? > > TIA, > Allan. I don't know if this is possible in your design, but Xilinx recommend that you don't use GSR in Virtex devices. So I would just write > foo : process (clk) > begin > if rising_edge(clk) then > if sync_reset = '1' then > ff <= '0'; > elsif clk_enable = '1' then > ff <= other_sig; > end if; > end if; > end process foo; Of course this will only get reset on configuration. Do you need the global reset functionally, i.e. do you use it in your application, rather than just letting reset on configuration happen? regards Alan -- Alan Fitch www.doulos.com
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