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
DJ Delorie <dj@delorie.com> wrote:
>
>nico@puntnl.niks (Nico Coesel) writes:
>> DJ just a side question: is there a version of PCB that runs on
>> Windows?
>
>Yes. It's on the sourceforge download page, just make sure you
>download the .exe and not the .tar.gz ;)
Way off-topic:
Got it! Nice to have it run on Windows. A few years ago I had PCB
running on an SGI Indy :-) I still can't tell whether the tracks are
bound to a netname or a grouped into a net by how they are connected
to the components. If I draw a track across an existing track, it
seems that it is connected to the track it crosses automagically. This
still allows for short circuits which may cause a track to be
associated with the wrong net. Sorry for being a real PITA about this,
but this was a major drawback of PCB and the behaviour I just saw
doesn't convince me the issue is fixed.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 137801jleslie48 wrote: > although I kept getting an error on this line: > > constant system_clock_period := 10ns; > --ERROR:HDLCompiler:806 - "source/loki_top_tb.vhd" Line 87. Syntax > error near constant > --ERROR:HDLCompiler:841 - "source/loki_top_tb.vhd" Line 87. Type error > near ns ; expected type void > --ERROR:HDLCompiler:69 - "source/loki_top_tb.vhd" Line 92. > system_clock_period is not declared > > anybody know whats wrong with the syntax??? > You need constant system_clock_period : TIME := 10 ns; VHDL is a strongly typed language :-) regards Alan P.S. Strictly there should be a space between the time value and the unit as well, but some simulators will treat that as a warning. -- Alan Fitch apfitch at ieee dot orgArticle: 137802
Back to running Aldec for simulation. 8.1 1864.SP1.04 Designs are not that large, V4 LX target device. All VHDL including test benches. Nothing too fancy. Only using functional at this time. Went to run the code coverage today and ran into a major problem. I have used CC for several years with this tool with no major problems. This is something new and I wonder if anyone has seen this or is aware of a work around. Ok, the problem. After running CC, I look at the test bench and it shows that the CC tool stopped executing part way through them. I do a lot of reporting in the test benches and can see everything is working. So, its not that the simulator stops running, the waveforms all make it to the end. Just code coverage says it didn't make it to the end. If I look at the design files, it shows various parts of the design that did not get used. However, again, I know they were used based on the waveforms and my reporting. I then removed several sections of the testbench where it seemed to cause the problem and made a second attempt. I also set breakpoints in the design. During simulation all of the break points were hit, simulation finshed with no problems, reports and waveforms were again correct. Looking at CC, again it shows that the test bench did not run all the way through. And again it showed sections of the design that did not get used, even though during simulation the break points for these sections tripped. the test bench did stop in a whole different location and it almost appears that there may be some sort of limit to CC that it can only handle so many cycles. It gives no warnings that it ran out of memory or such. Very strange. Again, I have used this simulator for several years with no problems (well, nothing like this). So I am guessing it is a new problem. Thanks for any information you can provide.Article: 137803
nico@puntnl.niks (Nico Coesel) writes: > If I draw a track across an existing track, it seems that it is > connected to the track it crosses automagically. Turn on "Auto enforce DRC clearance" and it won't let you make connections that violate the loaded netlist.Article: 137804
DJ Delorie <dj@delorie.com> wrote:
>
>nico@puntnl.niks (Nico Coesel) writes:
>> If I draw a track across an existing track, it seems that it is
>> connected to the track it crosses automagically.
>
>Turn on "Auto enforce DRC clearance" and it won't let you make
>connections that violate the loaded netlist.
I just tried it. It works indeed. Neat! You should have that option on
by default :-)
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
"If it doesn't fit, use a bigger hammer!"
--------------------------------------------------------------
Article: 137805Hey Guys, I am trying to simulate a large design but am hampered by the DCM_SP LOCKED output not simulating, which is a known issue : http://www.xilinx.com/support/answers/30812.htm I realise SP3 will fix this but don't have the ability to download files of that magnitude at the moment, and I wondered if anyone had a fixed source model of DCM_SP they could send me. Thanks, GintsArticle: 137806
On Thu, 29 Jan 2009 05:00:51 -0800 (PST), jleslie48 <jon@jonathanleslie.com> wrote: >On Jan 28, 8:07 pm, Brian Drummond <brian_drumm...@btconnect.com> >> (LOKI? He's our cat!) >Loki - god of mischef. Yup - that's our cat... -BrianArticle: 137807
On Jan 29, 4:17=A0pm, Alan Fitch <apfi...@invalid.invalid> wrote: > jleslie48 wrote: > > although I kept getting an error on this line: > > > =A0constant system_clock_period :=3D 10ns; > > --ERROR:HDLCompiler:806 - "source/loki_top_tb.vhd" Line 87. Syntax > > error near constant > > --ERROR:HDLCompiler:841 - "source/loki_top_tb.vhd" Line 87. Type error > > near ns ; expected type =A0void > > --ERROR:HDLCompiler:69 - "source/loki_top_tb.vhd" Line 92. > > system_clock_period is not declared > > > anybody know whats wrong with the syntax??? > > You need > > =A0 constant system_clock_period : TIME :=3D 10 ns; > > VHDL is a strongly typed language :-) > > regards > Alan > > P.S. Strictly there should be a space between =A0the time value and the > unit as well, but some simulators will treat that as a warning. > > -- > Alan Fitch > apfitch at ieee > dot org you da man... will try that out first thing in the AM.Article: 137808
rickman <gnuarm@gmail.com> wrote: (snip) > I believe the same is true for VHDL. But the code above is not using > an operator. It is using a conditional assignment based on an IF. > o2_int <= '1'; > if o1_int = '1' then > o2_int <= '0'; > end if; > The IF evaluates the signal literally. If it is a '1', then o2_int > gets '0'. If it is ***any*** other value o2_int retains '1'. I believe verilog is slightly less literal, but in this case with the same result. For verilog, if o1_int was 1`bz then o1_int=1 would be 1`bx. For if(), 1`b1 is true, everything else is false. Verilog has the === and !== operators for literal comparisons including 1`bx and 1`bz. I might have written assign o2_int = ~o1_int; or assign o2_int = !o1_int; both of which will assign 1`bx if o1_int is 1`bz. > I would not use tristate logic, partly because of the problem Andreas > points out, but mainly because it can be confusing and misleading. I > think it is much better to change the code to match the current > devices than to retain the code in an obsolete form. I don't think > there are any issues of "but this code works"! If you are porting it > to a new device and most likely new tools, it has to be verified from > scratch anyway. So fixing the out of date code would not add > significantly to the cost. There are some people interested in porting old computer designs, such as the Apple II, to FPGA. In that case, it might make sense to include the original tristate lines. Any design with real (74LS367 for example) tristate buffers should work, but it might be that some such designs depend on the bus staying in the previous state for some fraction of a second after all buffers are disabled. That would seem to me a design bug, but one that might still exist. I don't know what the synthesis tools do if you put a keeper on the tristate bus. -- glenArticle: 137809
On Jan 27, 11:52=A0pm, secure...@gmail.com wrote: > Hi Rob Gaddi > > > Same way you manually do 600 of anything else, one at a time. > > ... :-) ... I imagine that it is the best. > > Thnaks. > > Kappa. Speaking as somebody who did this a few months ago (a board with two FG900s), prepare to spend a _lot_ of time routing. I'm not sure if I would do it again, given the choice.Article: 137810
hello, I would like to know why the x16 and x32 bus widths are not supported for encrypted bitstreams within virtex5 ? Thank youArticle: 137811
Hi all, I'm using EDK 10.1 and doing practise with a ML505 board. I'm trying to send input to the board through a ps2 keyboard but I don't find the XPS PS2 INTERFACE in the IP catalog. What must I do in order to add a PS2 interface in my design? Thanks! DanieleArticle: 137812
You have to select the "Display ... IP Cores" under Edit->Preferences...->IP Catalog and IP Config Catalog in the XPS. Matthias charlie78 schrieb: > Hi all, > I'm using EDK 10.1 > and doing practise with a ML505 board. > I'm trying to send input to the board > through a ps2 keyboard but > I don't find the XPS PS2 INTERFACE in > the IP catalog. > What must I do in order to add > a PS2 interface in my design? > Thanks! > > DanieleArticle: 137813
Hello Has anyone here successfully built a byteblaster clone. I have connected up the JTAG pins as specified and Quartus accepts that a byteblaster is fitted. I can see activity on TCLK, TMS and TDI at the FPGA and TDO is getting back to the parallel port but Quartus cannot auto detect anything. My system works with a proper Byteblaster but I have to give it back soon. Any ideas will be appreciated. ColinArticle: 137814
>You have to select the "Display ... IP Cores" under >Edit->Preferences...->IP Catalog and IP Config Catalog in the XPS. > >Matthias I did it but there isn't the PS2 INTERFACE in communication low-speed menù and I don't understand the reason why...Article: 137815
Hi everyone, I'm trying to program a Xilinx Virtex 5 (on Avnet PCI Express Development Kit board). I downloaded the bistream generated by the PIO example design which comes up with the PCI core (endpoint block 1.9) but when I reboot the system in order to recognize the board, the PC hangs forever. Do you have any idea about what it could depend on? By the way, the board is a x8 lane, but it is plugged in a x16 lane slot. Thanks in advance.Article: 137816
hello, I would like to know why the x16 and x32 bus widths are not supported for encrypted bitstreams within virtex5 ? Thank youArticle: 137817
colin pisze: > Hello > > Has anyone here successfully built a byteblaster clone. I have > connected up the JTAG pins as specified and Quartus accepts that a > byteblaster is fitted. I can see activity on TCLK, TMS and TDI at the > FPGA and TDO is getting back to the parallel port but Quartus cannot > auto detect anything. My system works with a proper > Byteblaster but I have to give it back soon. > > Any ideas will be appreciated. > > Colin Yes, use 74LV14 or LVC to keep sharp edges on JTAG lines AdamArticle: 137818
On Jan 29, 8:05 pm, jleslie48 <j...@jonathanleslie.com> wrote: > On Jan 29, 4:17 pm, Alan Fitch <apfi...@invalid.invalid> wrote: > > > > > jleslie48 wrote: > > > although I kept getting an error on this line: > > > > constant system_clock_period := 10ns; > > > --ERROR:HDLCompiler:806 - "source/loki_top_tb.vhd" Line 87. Syntax > > > error near constant > > > --ERROR:HDLCompiler:841 - "source/loki_top_tb.vhd" Line 87. Type error > > > near ns ; expected type void > > > --ERROR:HDLCompiler:69 - "source/loki_top_tb.vhd" Line 92. > > > system_clock_period is not declared > > > > anybody know whats wrong with the syntax??? > > > You need > > > constant system_clock_period : TIME := 10 ns; > > > VHDL is a strongly typed language :-) > > > regards > > Alan > > > P.S. Strictly there should be a space between the time value and the > > unit as well, but some simulators will treat that as a warning. > > > -- > > Alan Fitch > > apfitch at ieee > > dot org > > you da man... will try that out first thing in the AM. dumb-ass syntax checker. the CONSTANT declaration must be after ARCHITECTURE but before the BEGIN Doh.Article: 137819
jleslie48 wrote: > On Jan 29, 8:05 pm, jleslie48 <j...@jonathanleslie.com> wrote: >> On Jan 29, 4:17 pm, Alan Fitch <apfi...@invalid.invalid> wrote: >> >> >> >>> jleslie48 wrote: >>>> although I kept getting an error on this line: >>>> constant system_clock_period := 10ns; >>>> --ERROR:HDLCompiler:806 - "source/loki_top_tb.vhd" Line 87. Syntax >>>> error near constant >>>> --ERROR:HDLCompiler:841 - "source/loki_top_tb.vhd" Line 87. Type error >>>> near ns ; expected type void >>>> --ERROR:HDLCompiler:69 - "source/loki_top_tb.vhd" Line 92. >>>> system_clock_period is not declared >>>> anybody know whats wrong with the syntax??? >>> You need >>> constant system_clock_period : TIME := 10 ns; >>> VHDL is a strongly typed language :-) >>> regards >>> Alan >>> P.S. Strictly there should be a space between the time value and the >>> unit as well, but some simulators will treat that as a warning. >>> -- >>> Alan Fitch >>> apfitch at ieee >>> dot org >> you da man... will try that out first thing in the AM. > > dumb-ass syntax checker. the CONSTANT declaration must be after > ARCHITECTURE > > but before the BEGIN > > Doh. > > What us VHDL people call "the declarative region". All declarations must be in a declarative region. You can declare a constant in a process, procedure, function or architecture but it's got to be in front of the appropriate "begin". regards Alan P.S. I know there are other places declarations are allowed but "that's not important right now" -- Alan Fitch Doulos http://www.doulos.comArticle: 137820
On Jan 30, 11:45 am, Alan Fitch <alan.fi...@spamtrap.com> wrote: > jleslie48 wrote: > > On Jan 29, 8:05 pm, jleslie48 <j...@jonathanleslie.com> wrote: > >> On Jan 29, 4:17 pm, Alan Fitch <apfi...@invalid.invalid> wrote: > > >>> jleslie48 wrote: > >>>> although I kept getting an error on this line: > >>>> constant system_clock_period := 10ns; > >>>> --ERROR:HDLCompiler:806 - "source/loki_top_tb.vhd" Line 87. Syntax > >>>> error near constant > >>>> --ERROR:HDLCompiler:841 - "source/loki_top_tb.vhd" Line 87. Type error > >>>> near ns ; expected type void > >>>> --ERROR:HDLCompiler:69 - "source/loki_top_tb.vhd" Line 92. > >>>> system_clock_period is not declared > >>>> anybody know whats wrong with the syntax??? > >>> You need > >>> constant system_clock_period : TIME := 10 ns; > >>> VHDL is a strongly typed language :-) > >>> regards > >>> Alan > >>> P.S. Strictly there should be a space between the time value and the > >>> unit as well, but some simulators will treat that as a warning. > >>> -- > >>> Alan Fitch > >>> apfitch at ieee > >>> dot org > >> you da man... will try that out first thing in the AM. > > > dumb-ass syntax checker. the CONSTANT declaration must be after > > ARCHITECTURE > > > but before the BEGIN > > > Doh. > > What us VHDL people call "the declarative region". All declarations must > be in a declarative region. You can declare a constant in a process, > procedure, function or architecture but it's got to be in front of the > appropriate "begin". > > regards > Alan > > P.S. I know there are other places declarations are allowed but "that's > not important right now" > > -- > Alan Fitch > Douloshttp://www.doulos.com I have no problem with that, only that the syntax checker could of told me that: "error:xyz: constant declaration not allowed in concurrent block. " instead of sending me on a wild goose chase about "type"Article: 137821
On Jan 30, 4:00 am, colin <colin_toog...@yahoo.com> wrote: > Hello > > Has anyone here successfully built a byteblaster clone. I have > connected up the JTAG pins as specified and Quartus accepts that a > byteblaster is fitted. I can see activity on TCLK, TMS and TDI at the > FPGA and TDO is getting back to the parallel port but Quartus cannot > auto detect anything. My system works with a proper > Byteblaster but I have to give it back soon. > > Any ideas will be appreciated. > > Colin Get a used one on eBay, of buy one OEM from the same place Altera does. ALArticle: 137822
On Jan 29, 8:27 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > rickman <gnu...@gmail.com> wrote: > > (snip) > > > I believe the same is true for VHDL. But the code above is not using > > an operator. It is using a conditional assignment based on an IF. > > o2_int <= '1'; > > if o1_int = '1' then > > o2_int <= '0'; > > end if; > > The IF evaluates the signal literally. If it is a '1', then o2_int > > gets '0'. If it is ***any*** other value o2_int retains '1'. > > I believe verilog is slightly less literal, but in this case > with the same result. For verilog, if o1_int was 1`bz then > o1_int=1 would be 1`bx. For if(), 1`b1 is true, everything else > is false. Verilog has the === and !== operators for literal > comparisons including 1`bx and 1`bz. > > I might have written > > assign o2_int = ~o1_int; > > or > > assign o2_int = !o1_int; > > both of which will assign 1`bx if o1_int is 1`bz. > > > I would not use tristate logic, partly because of the problem Andreas > > points out, but mainly because it can be confusing and misleading. I > > think it is much better to change the code to match the current > > devices than to retain the code in an obsolete form. I don't think > > there are any issues of "but this code works"! If you are porting it > > to a new device and most likely new tools, it has to be verified from > > scratch anyway. So fixing the out of date code would not add > > significantly to the cost. > > There are some people interested in porting old computer > designs, such as the Apple II, to FPGA. In that case, it > might make sense to include the original tristate lines. > > Any design with real (74LS367 for example) tristate buffers > should work, but it might be that some such designs depend > on the bus staying in the previous state for some fraction > of a second after all buffers are disabled. That would > seem to me a design bug, but one that might still exist. > > I don't know what the synthesis tools do if you put a > keeper on the tristate bus. This is a good example of what I was thinking of. If I were porting such a design, although "port" is not really the correct term because there is no existing HDL code, I would not describe tri-state buffers in my code. I would describe a selection function which was a top level OR with each of the "tri-state" buffers being replaced by an AND gate. If there were timing issues that required the bus to "remember" the last driven state, I would add a latch with the enable driven by an OR of all of the individual enables. I don't see how you could expect a synthesis tool to do anything other than to replace the tri- state drivers with the OR-AND multiplexer and I don't see any reason to even try to duplicate a design at that level. RickArticle: 137823
On Jan 29, 7:07=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Thu, 29 Jan 2009 03:48:56 -0800 (PST), rickman wrote: > >No, Jonathan (the other one) did it correctly. =A0 > > Rick, please check your facts. =A0The line of code > > =A0 constant S: string (0 to 3) :=3D "0123"; > > WILL NOT COMPILE in any standards-compliant tool. > I can believe that some synthesis tools bend the > rules and permit 0-based indexing of strings, but > they should not. I don't think I said anything to the contrary. Johnathan's original code was written 1 based and I changed it to 0 based. Perhaps you are looking at subsequent code he has posted in reply to my suggestions. > >It would really bug me to have to use > >1 based indexing for strings in synthesized code. > > It bugs me too, but rules is rules. =A0It is quite > unusual to use strings in synthesis, partly because > some older synthesis tools didn't handle CHARACTER > data, but it works now in all the tools I've seen, > so no reason why we shouldn't go ahead - correctly. Yes, I have never needed to use a string in synthesis and I have never had to index into a string even in a test bench. I don't have the code handy, but my string use was in reading a command file to control the actions and timing of test benches. The line was read intact and then various operations searched for the commands and values in the command. > >optimization really should be left for the cases > >where it is worth the cost. > > It's nothing to do with optimization; if the code is > illegal, optimization doesn't happen. I don't know what you are talking about here. I am not suggesting that invalid code should be used. I am saying that I don't have a need to try to optimize string related code. If I did, I would look to see what was produced and if needed I could define my own string type. There is little special about VHDL. Much of it is just code written to define extensions to the language that can be written in different ways if needed. > >Do you know how this will synthesize? =A0If my string is 1 to 4, will > >the counter be two bits or three? =A0I think I know the answer, it will > >be three. > > I completely agree with you. =A0If you are so desperate to have a > counter that's one bit shorter, you could easily define your > own new string type One bit out if *each* counter that accesses a string, plus and logic driven by those counters and so on and so forth. Depending on the application, it could be a significant amount of waste. > =A0 type stringZ is array (natural range <>) of character; > > and use that - but, of course, you would then lose all > the built-in TEXTIO functionality that is so useful in > testbenches. Unless you define a conversion which would be quite simple I expect. RickArticle: 137824
On Fri, 30 Jan 2009 12:51:11 -0800 (PST), rickman wrote: >I don't think I said anything to the contrary. Johnathan's original >code was written 1 based and I changed it to 0 based. Perhaps you are >looking at subsequent code he has posted in reply to my suggestions. OK, that may be so. It looks as though there has been some traffic on/around this thread that I didn't see, for whatever reason. Apologies if I misinterpreted the history of the thread. > my string use was in reading a command file to control >the actions and timing of test benches. The line was read intact and >then various operations searched for the commands and values in the >command. Most of VHDL's (rather limited) string manipulation facilities are sufficiently well packaged that you almost never need to index your way through a string by hand. I've only rarely found any reason to do so. I guess you found the same. [concerning the extra bit that you might need for indexing a 1-based string] >One bit out if *each* counter that accesses a string, plus and logic >driven by those counters and so on and so forth. Depending on the >application, it could be a significant amount of waste. I dispute that; the extra bit only arises in the special situation where your string has exactly 2**N characters, in which case 0-based needs N bits to index but 1-based needs N+1 bits. In all other situations there is no additional cost to 1-based. Unless you have a system that takes perverse delight in using 32- or 64-character strings, I can't believe it makes any real difference. >> type stringZ is array (natural range <>) of character; >> and use that - but, of course, you would then lose all >> the built-in TEXTIO functionality that is so useful in >> testbenches. > >Unless you define a conversion which would be quite simple I expect. sure. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.
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