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
Hi I am trying to compile a bit of VHDL code on Xilinx SW. The target is a Spartan2. I get the following error message FATAL_ERROR:HDLParsers:vhptype.c:172:$Id: vhptype.c,v 1.6 2001/10/12 21:32:28 weilin Exp $:200 - INTERNAL ERROR... while parsing C:/project/sensor/vhdl/mult16/mult16.vhd line 716. Contact your hot line. Process will terminate. To resolve this error, please consult the Answers Database and other online resources at http://support.xilinx.com. If you need further assistance, please open a Webcase by clicking on the "WebCase" link at http://support.xilinx.com I did not get this error when I compiled the code for4/8 bits.I get this error when I compile for a 16 bit application. Now, the code is lengthy & am really not sure if I can paste the entire code .And I am pretty clueless as to which specific area of the code is causing the error.But the line number (716) which shows up on the error message is the last line of the source code. I did look up the previous thread on the same topic and the help suggested there is not applicable in my case.(I am not using any aliases in the code) I wonder if anyone could throw some light on the reason for this error. Thank you AnukulArticle: 62251
I have two designs that were done in old Xilinx Foundation Software - 1.5 (schematics can be opened in later versions and viewed). One design tests the seven segment LEDS of a demo board and cycles through from 0 to 9 no problems. The other design incorporates a timer but is giving scattered segments on the seven segment display. As I am unable to open these files on ISE I am hoping someone would like to take a quick look at the two files and see if the basic schematics show any notable differences concerning the seven segment problem. As the designs were made for the same board - and one design works perfectly it may only be some pin assignment differences. Please email me if interested - would be much appreciated. ZArticle: 62252
6.1 clearly has some problems. I recommend that you steer clear of it until these problems are cleared up. I intalled it on 3 computers and 2 had problems. What tech support wanted me to do made no sense (strip everything out of the path but xilinx). I am sorry, but I am not being paid to debug Xilinx's problems. Tom SeimArticle: 62253
Thanks, Yes you are right, I had a look in FPGA editor, and the two macros are sharing a CLB. This leads me to another question. Is there any way to stop the timing tools reporting on such path?? Or can I stop the place and route tools sharing CLBs between macros. Thanks again, you help has been invaluable. Allan Herriman wrote: > On Thu, 23 Oct 2003 14:37:24 +1000, Kload <aperson@somewhere.com> > wrote: > > >>Hi all, >> >>I have an unusual timing problem that I hope someone can help with. >>I've constrained the delay between flip flops within one of my VHDL >>macros (called COLFILT) to bo 20ns. This constraint is violated which >>in itself is not strange. The odd thing is that the paths violating the >>constraint all seem pass through another VHDL macro (called ROBAVG - >>variable SReg) which is in the same data path as COLFILT but the two >>have no direct connections. >> >>(Note: INT_ColumnFilter is a TNM that defines all flipflops in the >>COLFILT VHDL macro) >> >>Can anyone clear this up for me? What is a reference to ROBAVG doing in >> a timing path that should only include elements from COLFILT? I've >>attached an example from the timing analyser and associated code for >>your reference. > > > Each CLB contains eight flip flops and LUTs. A given CLB may contain > logic from separate parts of your design (e.g ROBAVG and COLFILT). > > The CLB "name" is taken from one of the flip flops or LUTs it > contains. Thus your "COLFILT" timing paths may seem to be passing > through "ROBAVG", even though there is no actual relationship between > them (except that they are sharing a CLB). > > BTW, use fpga_editor in future. > > Regards, > Allan.Article: 62254
Hi again, Following up on my earlier post, I have come across another unusual timing problem. It seems I have timing paths that pass through flip flops. I've attached an example from the timing report. Using FPGA Editor to examine the implementation I have been able to confirm that oath addrRange<1> and addrRange<2> are flip flop outputs. In both cases the inputs seems to come through the carry logic, though and XOR gate, through a multiplexer to the D input of the flip flop. Thanks in advance for your help. -------------------------------------------------------------------------------- Slack: -2.537ns path ROBAVGSEG2/endAddr<8> to ROBAVGSEG2/dataSum<16> relative to 20.000ns delay constraint Path ROBAVGSEG2/endAddr<8> to ROBAVGSEG2/dataSum<16> contains 10 levels of logic: Path starting from Comp: CLB_R22C54.S0.CLK (from CLK180) To Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- -------- CLB_R22C54.S0.YQ Tcko 1.372R ROBAVGSE/eAddr<8> ROBAVGSE/eAddr_reg<8> CLB_R21C58.S1.F1 net (fanout=6) 2.258R ROBAVGSE/eAddr<8> CLB_R21C58.S1.X Tilo 0.738R ROBAVGSE/syn6957 ROBAVGSE/C2679 CLB_R25C58.S1.G3 net (fanout=1) 1.633R ROBAVGSE/syn6957 CLB_R25C58.S1.Y Tilo 0.738R ROBAVGSE/C1432 ROBAVGSE/C2677 CLB_R25C58.S1.F3 net (fanout=2) 0.130R ROBAVGSE/syn6963 CLB_R25C58.S1.X Tilo 0.738R ROBAVGSE/C1432 ROBAVGSE/C2676 CLB_R23C55.S1.F4 net (fanout=16) 1.975R ROBAVGSE/C1432 CLB_R23C55.S1.X Tilo 0.738R ROBAVGSE/C1291/N21 ROBAVGSE/C2663 CLB_R24C59.S1.F1 net (fanout=1) 1.871R ROBAVGSE/C1291/N21 CLB_R24C59.S1.COUT Topcyf 1.445R ROBAVGSE/addrRange<1> ROBAVGSE/C1281/C4/C0 ROBAVGSE/C1281/C4/C2 ROBAVGSE/C1281/C5/C2 CLB_R23C59.S1.CIN net (fanout=1) 0.000R ROBAVGSE/C1281/C5/C2/O CLB_R23C59.S1.Y Tciny 0.590R ROBAVGSE/addrRange<2> ROBAVGSE/C1281/C6/C2 ROBAVGSE/C1281/C7/C1 CLB_R25C60.S1.F2 net (fanout=6) 1.577R ROBAVGSE/N7566 CLB_R25C60.S1.X Tilo 0.738R ROBAVGSE/syn2456 ROBAVGS2/C2558 CLB_R26C67.S0.G2 net (fanout=7) 1.766R ROBAVGSE/syn2456 CLB_R26C67.S0.Y Tilo 0.738R ROBAVGSE/C92/N85 ROBAVGSE/C2458 CLB_R21C75.S1.CE net (fanout=9) 2.544R ROBAVGSE/C92/N85 CLB_R21C75.S1.CLK Tceck 0.948R ROBAVGSE/dSum<16> ROBAVGSE/dSum_reg<16> ------------------------------------------------- Total (8.783ns logic, 13.754ns route) 22.537ns (to CLK180) (39.0% logic, 61.0% route)Article: 62255
To everyone: I realize that this is not ideal, but the fact "it works" underline at least: 1) There is significant interest in FPGA tools on Linux : Possibly the most important! 2) This is really feasible and requires minimal work (at least for Red Hat). So we (users) may expect someone at Altera to be motivated, pickup the ball, and treat this seriously. Altera has very talented engineers, and there is no doubt in my mind that very soon a nice install, possibly similar to the one of Open Office (GUI based) will be available for Linux. 3) Mandrake: I have also tried Mandrake 9.1 and did not get anywhere! This is a pity, because Mandrake is most-likely the most user-friendly Linux distribution: usually very easy to install. 4) Suse 9.0: did anyone try? Conclusion: Note that OpenOffice runs pretty much on any Linux distro. This is done at the (reasonable) cost of a fatter distribution, statically linked. Indeed some portion(s) of the code could be provided as source to allow easy run on most "current" Linux distros. Well, I guess this will now have a life of its own. Enjoy. Andre G. ----------------------------------------- "Subroto Datta" <sdatta@altera.com> wrote in message news:<Azwlb.6823$nF2.6135@newssvr17.news.prodigy.com>... > The topic of where to pick up the Red Hat Release was pointed to by another > user who tried Quartus 3.0 with a non Red Hat version of Linux. This has > been fixed for Quartus II 4.0. > > - Subroto Datta > Altera Corp. > > "Jan De Ceuster" <jandc@elis.ugent.be> wrote in message > news:bn59aj$tqj$1@gaudi2.UGent.be... > > >>And now it works... Maybe Altera should write a cleaner script that > > >>first checks if it's a Red Hat distribution... > > > > > > > > > Yes. But it would have been even better if they checked for the > > > *features* they need rather than checking the distribution. > > > > Indeed and I even had to manualy add some directories to the librarypath > to get > > everything up and running. It just doesn't look profecional to me. 2 days > work > > (at most) for a decent engineer and the scripts would have been perfect. > I'm a > > bit dissapointed... > > > > kind regards, > > Jan > >Article: 62256
"Jerry" <nospam@nowhere.com> wrote in message news:vpebkap3q9m03c@corp.supernews.com... > There is a book that has side by side examples of code, one written in VHDL > the other in Verilog. > Forgot the title but I'll send it tommorow. Doug Smith, "HDL Chip Design". [*****-SELF PUBLICITY ALERT *****] > "Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message > news:bn6gq8$15i5$1@agate.berkeley.edu... > > Luddite Me, who's forgotten most of the Verilog he once knew, needs to > > start doing serious HDL-based design. No more schematic-orphans for > > me. > > > > Are there good reference books for Verilog or VHDL? Ideally, > > something akin to Java in a Nutshell (Java), the Post Script Red > > (language reference) and Blue (tutorial and cookbook) series, or K&R? Have you looked at our Golden Reference Guides? Not for beginners, but then you're not a beginner :-) We give them away on courses, but you can buy them via the website (no e-commerce just yet, sorry; you have to fax back an order form): http://www.doulos.com/grg/index.html cheers -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 62257
"David Brown" <david@no.westcontrol.spam.com> wrote in message news:bn0j25$91g$1@news.netpower.no... > I'm using the downloadable version of ispLever for a verilog project on a > Lattice Mach 4 CPLD chip. The software has both Synplify and Leonardo > Spectrum available for synthesis. I can build the code (so far, anyway) > with either tool. Is there any reason why I should choose one over the > other? > Judging from the answers, I guess there isn't much of a difference for a small user using the free versions of the tools. Thanks anyway. DavidArticle: 62258
Hi, I have finded following error message in the synthesis process : Analyzing module <pga>. ERROR:Xst:853 - Unsupported item in port list for module <LDI_mpx>. The port list in module pga (reference module) is: LDI_mpx LDI_mpx ( .LDI (LDI), .LDI_TxRx (LDI_RX), .LDI_S (LDI_S), .go (READY), .CS0I (CS0I), .CS2I (CS2I), .RDI (RDI) //.WRI (WRI), //.LW_RI (LW_RI), //.BUFFER_WR (BUFFER_MPX_LDI) ); I don't find where is the unsupported item.The module LDI_mpx was finded correct for synthesis.Article: 62259
Hi, I've succesfully build a microblaze system with external interrupt and my own IP core (using the opb slave template in the EDK). The interrupt is connected to a dip-switch. In the ISR I'm writing some data to my own IP core (which is an OPB slave). My OPB slave is reading some other dip-switches and put the result to some LEDs (yes I'm using an evaluation board ;). So far everything is ok. Now comes the problem: the expected behaviour is dependent of the code in the ISR. If I've the following ISR: void dip_isr(void) { *(opb_mycore_base) = 0x12345678; // Write the value of j to the LED // XGpio_DiscreteWrite(&gp_out, 0); #ifdef USE_INTC XIntc_mAckIntr(XPAR_MY_INTC_BASEADDR, XPAR_SYSTEM_MY_INT_MASK); #endif } it's not working. But if I enable the XGpio write, it is working. And at last, if I do the XGpio write first and than the write to the OPB slave (opb_mycore) it's again not working anymore. In all three situations, the code is coming in the ISR (I see that, because there is no output at the uart anymore, which is done in the main program). I don't know what is happening. Can anybody help me?! TIA, FrankArticle: 62260
Greetings, Kload. The timing report that you see does not show your flops driving NET elements, but their inclusion in the timing report is misleading for new engineers. The Xilinx devices work with "slices" which are treated as a single element within the tools to some degree. Each slice can contain many smaller parts such as LUTs, registers, MUXCY elements, XORCYs, MUXF5s, and so on. The first name in one "group" from the CLB timing element (such as Tilo or Topcyf) corresponds to the name the Xilinx tool gave to the entire slice. If you have the regular XIlinx tools (rather than just Webpack) you can use the FPGA Editor to look at the place & route implementation inside the device. If you find the ROBAVGSE/addrRange<1> COMPonent and open it up to view the innerds of that slice, you'll see the register you were worried about as well as the other piece-parts that make up that slice to include the named elements: ROBAVGSE/C1281/C4/C0 ROBAVGSE/C1281/C4/C2 ROBAVGSE/C1281/C5/C2 Which actually *are* part of your carry chain. The "net" items are the actual signals that propagate out of the slice. Your flop isn't part of the carry chain logic, but is packed in the same slice as that change, affecting performance very little. Your difficulties with this timing path include not-so-great delay paths for the rather large amount of logic. If you can figure out how to reduce the levels of logic (number of LUTs passed through as indicated by the Tilo times) or can get the slices to pack closer together with floorplanning, RLOCed macros, or better placement methods (each is a slightly advanced design aspect) you should get better times. I've kept the "rule of thumb" that a 50% logic / 50% route is a "good" mix and longer routes can be cut down toward that 50/50 mix. Your numbers show on the bottom of your report item as "(39.0% logic, 61.0% route)". Enjoy the journey. - John_H Kload <aperson@somewhere.com> wrote in message news:<bn7r0c$peu$1@kraken.itc.gu.edu.au>... > Hi again, > > Following up on my earlier post, I have come across another unusual > timing problem. It seems I have timing paths that pass through flip > flops. I've attached an example from the timing report. Using FPGA > Editor to examine the implementation I have been able to confirm that > oath addrRange<1> and addrRange<2> are flip flop outputs. In both cases > the inputs seems to come through the carry logic, though and XOR gate, > through a multiplexer to the D input of the flip flop. > > Thanks in advance for your help. > > -------------------------------------------------------------------------------- > Slack: -2.537ns path ROBAVGSEG2/endAddr<8> to > ROBAVGSEG2/dataSum<16> relative to > 20.000ns delay constraint > > Path ROBAVGSEG2/endAddr<8> to ROBAVGSEG2/dataSum<16> contains 10 levels > of logic: > Path starting from Comp: CLB_R22C54.S0.CLK (from CLK180) > To Delay type Delay(ns) Physical Resource > Logical Resource(s) > ------------------------------------------------- -------- > CLB_R22C54.S0.YQ Tcko 1.372R ROBAVGSE/eAddr<8> > ROBAVGSE/eAddr_reg<8> > CLB_R21C58.S1.F1 net (fanout=6) 2.258R ROBAVGSE/eAddr<8> > CLB_R21C58.S1.X Tilo 0.738R ROBAVGSE/syn6957 > ROBAVGSE/C2679 > CLB_R25C58.S1.G3 net (fanout=1) 1.633R ROBAVGSE/syn6957 > CLB_R25C58.S1.Y Tilo 0.738R ROBAVGSE/C1432 > ROBAVGSE/C2677 > CLB_R25C58.S1.F3 net (fanout=2) 0.130R ROBAVGSE/syn6963 > CLB_R25C58.S1.X Tilo 0.738R ROBAVGSE/C1432 > ROBAVGSE/C2676 > CLB_R23C55.S1.F4 net (fanout=16) 1.975R ROBAVGSE/C1432 > CLB_R23C55.S1.X Tilo 0.738R ROBAVGSE/C1291/N21 > ROBAVGSE/C2663 > CLB_R24C59.S1.F1 net (fanout=1) 1.871R ROBAVGSE/C1291/N21 > CLB_R24C59.S1.COUT Topcyf 1.445R ROBAVGSE/addrRange<1> > ROBAVGSE/C1281/C4/C0 > ROBAVGSE/C1281/C4/C2 > ROBAVGSE/C1281/C5/C2 > CLB_R23C59.S1.CIN net (fanout=1) 0.000R ROBAVGSE/C1281/C5/C2/O > CLB_R23C59.S1.Y Tciny 0.590R ROBAVGSE/addrRange<2> > ROBAVGSE/C1281/C6/C2 > ROBAVGSE/C1281/C7/C1 > CLB_R25C60.S1.F2 net (fanout=6) 1.577R ROBAVGSE/N7566 > CLB_R25C60.S1.X Tilo 0.738R ROBAVGSE/syn2456 > ROBAVGS2/C2558 > CLB_R26C67.S0.G2 net (fanout=7) 1.766R ROBAVGSE/syn2456 > CLB_R26C67.S0.Y Tilo 0.738R ROBAVGSE/C92/N85 > ROBAVGSE/C2458 > CLB_R21C75.S1.CE net (fanout=9) 2.544R ROBAVGSE/C92/N85 > CLB_R21C75.S1.CLK Tceck 0.948R ROBAVGSE/dSum<16> > ROBAVGSE/dSum_reg<16> > ------------------------------------------------- > Total (8.783ns logic, 13.754ns route) 22.537ns (to CLK180) > (39.0% logic, 61.0% route)Article: 62261
"Nial Stewart" <nial@spamno.nialstewart.co.uk> wrote in message news:<3f96a97a$0$10970$fa0fcedb@lovejoy.zen.co.uk>... > I always get an error window with 'File :Not Exist' > when I try to load a source file. > > Nial. I download this program. This program generates tbench for inout port too. Interface and help is very good.Article: 62262
Can someone help me interpret the following Virtex2 TRCE report please? Why is it saying the BUFG output has both period and offset unconstrained? It seemed to push my period constraint through the DCM just fine as coverage is 90%; so why would it say my BUFG output has unconstrained period analysis?. My project is connected in a fairly standard way basically consisting of a non-clock pin into IBUFG into a DCM. The CLK0 of that DCM gois into a BUFG. The output of that BUFG goes back to the feedback on the DCM as well as thousands of other places including RAMBs, FFs, and one OBUF/PAD combo. Thanks for any help. I'm using Xilinx 6.1.2. You may have to paste this into a fixed-width font. ---------------------------------------------------------------------------- ---- Constraint | Requested | Actual | Logic | | | Levels ---------------------------------------------------------------------------- ---- NET "IBUFG_to_DCMs_INCLK" PE | N/A | N/A | N/A RIOD = 15 nS HIGH 50.000000 % | | | ---------------------------------------------------------------------------- ---- PERIOD analysis for net "DCMs_CLK0_to_BUFG| 15.000ns | 14.908ns | 8 " derived from NET "IBUFG_to_DCMs_INCLK" | | | PERIOD = 15 nS HIGH 50.000000 % | | | ---------------------------------------------------------------------------- ---- TIMEGRP "all_bus" OFFSET = OUT 3.800 nS A | 3.800ns | 3.468ns | 0 FTER COMP "CLKs_IOPAD_to_IBUFG" | | | ---------------------------------------------------------------------------- ---- TIMEGRP "all_bus" OFFSET = IN 1.200 nS BE | 1.200ns | -0.046ns | 1 FORE COMP "CLKs_IOPAD_to_IBUFG" | | | ---------------------------------------------------------------------------- ---- Unconstrained period analysis for net | N/A | 3.219ns | 2 "BUFG_to_EVERYTHING" | | | ---------------------------------------------------------------------------- ---- Unconstrained OFFSET IN BEFORE analysis f | N/A | 15.212ns | 6 or clock "BUFG_to_EVERYTHING" | | | ---------------------------------------------------------------------------- ---- Unconstrained OFFSET OUT AFTER analysis f | N/A | 16.690ns | 2 or clock "BUFG_to_EVERYTHING" | | | ---------------------------------------------------------------------------- ---- Unconstrained path analysis | N/A | 2.378ns | 4 ---------------------------------------------------------------------------- ----Article: 62263
Divided clock seems synchronous to original clk in terms it is stable on clk edage. On the other hand, synchronous signals should switch simultaneusly while divided signal is calculated on the clk egdage; hence, it switches after Thold and the condition is not met. I understand principles of asynchronous communication. Should I treat divided clock as an asynchronous clock domain? Any references are appretiated.Article: 62264
Tom Seim wrote: > > 6.1 clearly has some problems. I recommend that you steer clear of it > until these problems are cleared up. I intalled it on 3 computers and > 2 had problems. What tech support wanted me to do made no sense (strip > everything out of the path but xilinx). I am sorry, but I am not being > paid to debug Xilinx's problems. Did you also install the service pack? -- 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 FAXArticle: 62265
On Thu, 23 Oct 2003 04:31:26 +0100, Ben Popoola <b.popoola@ntlworld.com> wrote: >I wish to connect a LED to the CONF_DONE pin of a cyclone FPGA to >indicate when configuration has been completed. > >The CONF_DONE pin is an open collector pin that is pulled high via a 10K >resistor when configuration is completed. > >Do I connect my circuit board indicator to ground (through another >resistor) or should I connect it to the power rail? > >Thanks >Ben > Another idea which I just used on a cyclone design .. i put a small smt led from the NCEO pin to ground via a 220 resistor, the led flashes when power is first applied during configuration, if the led remains on there is a problem. I like this particularly for multiple cyclones loading from one flash device since each cyclone can have it's own led beside the chip indicating which cyclone did not configure instead of using the conf_done pins because these are tied together for a multiple cyclone string and cannot point to the chip.Article: 62266
Hi, I've searched the archive for this newsgroup, and read the FAQ. I'm wondering if anybody can help me locate an 802.11a or g phy VHDL, Verilog or other implementation. Thanks, David dbeberman@earthlink.netArticle: 62267
Vaughn Betz <vbetz@altera.com> wrote: >> > The only times I've seen the warning above is when Quartus detects > that your clock signal will never toggle (i.e. it is either a logic > '0' or '1' all the time, due to the logic feeding it reducing to > that). This almost always indicates a design error. So I think this > is more basic than making clock settings etc. to tell Quartus your > clock frequency requirements and such -- Quartus has detected that > this circuit is almost certainly not what you want. You should > examine your HDL to see exactly what logic is generating this clock. I had exactly this warning once when I was using the wrong library (std_logic_signed instead of std_logic_unsigned !) RomanArticle: 62268
> Divided clock seems synchronous to original clk in terms it is stable on > clk > edage. On the other hand, synchronous signals should switch simultaneusly > while divided signal is calculated on the clk egdage; hence, it switches > after Thold and the condition is not met. I understand principles of > asynchronous communication. Should I treat divided clock as an > asynchronous > clock domain? Any references are appretiated. > > Valentin, For all but the simplest of designs divided clocks should be treated as asynchronous and avoided if possible. There are several reasons for this. 1) Your divided clock will have a small delay relative to the real clock. If you use this to clock a register which takes in a signal clocked from the original clock domain it may be possible for the setup/hold to be violated or data to be taken when it shouldn't have been (i.e a clock early). I think you were implying this above. 2) If you have logic which works accross the two clock domains e.g. data clocked from main clock domain goes through logic and is registed on divided clock domain or vice-versa then the synthesis tool may have a hard time performing optimization on logic in that part of the design. 3) Unless you have spare high-speed global resources in your design and the target technology allows the connection of a register output onto these nets (most modern fpga's are okay with this!) then the divided clock may get routed on the normal routing nets. If you have lots of registers driven from the divided clock the fanout may start to become significant and hence the skew between the clock domains will get larger. If the skew starts to become significant it then becomes more difficult to ensure that the design will work over all temperature/voltage conditions as this will introduce skew between registers on the divided domain aswell as between the divided and main clock domain. To overcome this the synthesis/place&route tools may try to insert buffers to split down the net. This may in turn introduce more skew between some registers on your divided net. So to overcome these issues I would suggest trying alternative method of coding to reduce this problem to a minimum. The way I do things if I want a slower clock is as follows: For example, say I want a clock that is 1/3 the system clock, I would create a 2-bit counter that counts 0 to 2 and rolls over. When the counter equals 2 a signal EnableDiv3 is asserted to '1' (and is '0' for all other values). I then use this signal as a synchronous enable to the registers I want to run a 1/3 speed but still clock the registers off the system clock. EnableGen : process (nReset, Clock) begin if (nReset = '0') then EnableCount <= 0; EnableDiv3 <= '0'; elsif rising_edge (Clock) then if (EnableCount = 2) then EnableCount <= 0; EnableDiv3 <= '1'; else EnableCount <= EnableCount + 1; EnableDiv3 <= '0'; end if; end if; end process; SomeRegister : process (nReset, Clock) begin if (nReset = '0') then MySignalReg <= '0'; elsif rising_edge (Clock) then if (EnableDiv3) then MySignalReg <= MyDataValue; else MySignalReg <= MySignalReg; end if; end if; end process; This solves 1) and 2) above. For item 3) there is still the problem of high fan-out on the enable signal. This will be solved by the synthesis/place&route tool by inserting buffers. However, in this case the registers are still clocked by the system clock so any skew on enable will be okay so long as it dosen't violate setup/hold at the destination registers. I hope this is what you were asking for. If you need anything else please let me know. Cheers, Pete.Article: 62269
"Klaus Vestergaard Kragelund" <klauskvik@hotmail.com> wrote in message news:3f96dcdd$0$9796$edfadb0f@dread14.news.tele.dk... > I bought a Parallel-III cable years ago, never used it though, but am > "close" to using it now. What were your problems with the cable? > The primary problem is not so much the cable, it's an odd (now rare/extinct) breed of parallel port: On some parallel ports, when the driver writes to the port, instead of just changing, the signal lines will be undefined for around 100 ns. This results in extra clock pulses and wrong data being clocked into the device. The cause is the behaviour of the x86 ISA bus (on which the parallel port still resides, even in my K7 machine): The write strobe is asserted before data i stable; For this reason the original IBM design calls for an edge triggered latch but some used level gated ones. Certain Compaq, Olivetti, and Siemens Pentium-1 machines had the problem. /KasperArticle: 62270
"Valentin Tihomirov" <valentin@abelectron.com> wrote in message news:<3f97eb7a$1_1@news.estpak.ee>... > Divided clock seems synchronous to original clk in terms it is stable on clk > edage. On the other hand, synchronous signals should switch simultaneusly > while divided signal is calculated on the clk egdage; hence, it switches > after Thold and the condition is not met. I understand principles of > asynchronous communication. Should I treat divided clock as an asynchronous > clock domain? Any references are appretiated. Are you referring to a divided clock that you're generating or a divided clock from a dedicated FPGA clocking resource? If you're generating the clock yourself, I'd suggest generating a one-pulse-wide enable signal every n cycles rather than a divide-by-n clock and use the enable for all the reduced-speed logic that would otherwise use the divided clock. The timing tools should be able to easily apply a multi-cycle constraint that you assiciate with the enable signal. The only logic that needs to have short propagation delays is the enable signal.Article: 62271
Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<219epvsvimu881ldkou9r98n7htdrc4guu@4ax.com>... > On 22 Oct 2003 10:24:06 -0700, Bassman59a@yahoo.com (Andy Peters) > wrote: > >Well, the full-up version of Leonardo lets you set Verilog parameters > >from the GUI or from a TCL script, whereas Synplify does not. This > >makes parameterized designs impossible in Synplify, so that tool's > >disqualified until that very important feature is added. (Ummmm, > >haven't parameters been a part of the language since the beginning???) > > Yes, and you have been able to set them (along with VHDL generics) in > Synplify since version 7.3. I know that Synplify has supported VHDL generics for ages -- it did when I bought a license in 2000 (whatever version that was). So, I guess I'll have to bug the FPGA vendor (QuickLogic) and find out when I can expect them to ship the Lite version of 7.3.x, since the current version is 7.2.1 (almost a year old, too). I'd use Leondardo Level 3 for the design, but for the life of me I cannot get the design to meet timing with it, whereas the Synplify Lite seems to have no problem. --aArticle: 62272
uselinux2000@yahoo.com (linux user) writes: > Altera has very talented engineers, and there is no doubt in my > mind that very soon a nice install, possibly similar to the one of > Open Office (GUI based) will be available for Linux. I've been a Linux user since 1993 and I'm very happy to see that Linux support from the major FPGA vendors is improving. However, I would like Altera and Xilinx to spend their efforts on other things than a GUI based install program. I recall all the problems I have had over the years with the Xilinx GUI based install program under Solaris. It would sit there for days flashing cute ads without installing anything :-( A simple tar would done the job. Of course you most likely need a way of specifying which devices and parts to install, but that's about it. Sometimes I install Linux software on file servers which don't even have X11. I would rather have better scripting capabilities, support for distributed processing (e.g. synthesis and place and route using a cluster to improve throughput), device programming support under Linux, Opteron 64-bit support, etc. > 4) Suse 9.0: did anyone try? I have tried on a SuSe 8 AMD64 system. Quartus II 3.0SP1 bails out with the message: Unknown Linux processor MWARCH: Undefined variable. But I think it should be possible to get it to run by hacking the scripts so that it will find its dynamic libraries, etc. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 62273
nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver) wrote in message news:<bn6gq8$15i5$1@agate.berkeley.edu>... > Luddite Me, who's forgotten most of the Verilog he once knew, needs to > start doing serious HDL-based design. No more schematic-orphans for > me. > > Are there good reference books for Verilog or VHDL? Ideally, > something akin to Java in a Nutshell (Java), the Post Script Red > (language reference) and Blue (tutorial and cookbook) series, or K&R? Nicholas, I still use Palnitkar's _Verilog HDL_ book, along with Stuart Sutherland's _Verilog 2001_ book and reference guides (which came with the book). There may be an updated version of the former -- I bought it in 1996 -- but it still covers most of the stuff that'll jog your memory. The latter explicitly details the differences between Verilog-95 and Verilog-2001. You probably want a copy of Janick Bergeron's _Writing Test Benches_, too, as it has a lot of good stuff. -aArticle: 62274
Petter Gustad <newsmailcomp6@gustad.com> writes: > I would rather have better scripting capabilities, support for I prefer to have my scripts under a source control system to be able to generate reproducible results. Not a designs which accidentally did or did not work because somebody on the project checked off an option several levels down in a GUI dialog box(1) (if DUI is "driving under influence", what is GUI?). For floorplanners and waveform viewers I use GUI's, but for plain synthesis, place and route, etc. I prefer scripts. I would like to say that Altera have spend quite a bit of effort putting scripting capabilities into Quartus. Quartus have TCL support, but the way you write your "code" is kind of weird: project add_assignment $top "" "" $clk GLOBAL_SIGNAL ON In order to check that the command had succeeded you have to check if the above command returned something like "assignment made". It also seems that the names and values for the various assignments might change from different Quartus releases. In later versions of Quartus Altera has added several smaller tools which do synthesis and elaboration, place and route, timing analysis, etc. This is good, even though I can't really see why bash is more suited than TCL to run the various commands/tools (assuming you make tclsh do dynamic linking). However, these tools seem to use a CSF (compiler settings file) to specify the various options to the different tools. This is a plain text file. What I don't like about this approach is that you loose the scripting ability. Of course you can write your own programs to generate these files. What I fear is that their format might change in future releases (please prove me wrong on this). What I would like is a *standard documented API* for the scripts. For the project assignment mentioned above I would like to have a command called something like "set_global_clock_signal $clk". If this command returned 0 (or some other predefined value) it has succeeded. Otherwise, I could a verbose error message by calling some other command (e.g. with the command name and result code as arguments). It would have been even better if the vendor would proved different scripting interfaces like TCL, Guile, Scheme, Perl, etc. to their tools so the users could pick their favorite scripting language. If the vendor provided the C API then users or others could generate a shell (they could provide TCL as a minimum or example) for their favorite language. Just my 2¢. Petter 1) CSF (compiler settings files) would of course solve this issue. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
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