From: Brian Drummond on 17 Jan 2010 18:12 On Sun, 17 Jan 2010 12:43:20 -0800 (PST), rickman <gnuarm(a)gmail.com> wrote: >On Jan 16, 10:23 pm, Gabor <ga...(a)alacron.com> wrote: >> On Jan 16, 12:59 pm, KMS <kms34...(a)gmail.com> wrote: >> >> > Hi, >> >> > I recommend you change your BOOLEANs to STD_LOGIC. >> If you're not trying to synthesize this logic, I'm not really >> clear why you shouldn't use booleans, but then I would >> normally have used Verilog. > >I'll second that. There is nothing about Booleans that are evil. The >two times I will replace a Boolean with a std_logic is when I know >this is a signal that will be important in simulation or when it is at >the top level of a synthesized design. I don't recall the exact issue >having other than std_logic or slv at the top level, but it is not a >big deal to work with that restriction. I'll third that. The issue I see with std_logic[_vector] ports at the top level is that whatever you use at the top level will be translated to std_logic[_vector] by synthesis and/or the post-PAR netlist generator. Therefore if you ever need to run a timing simulation, the easiest thing is to use these types from the start. Then your testbench will work with either behavioural or netlist versions. Of course you could use other port types, and generate a wrapper to convert port types for the netlist, but that's more work. If the tools were actually designed to support VHDL users who want to design at the most appropriate level of abstraction, they would auto-generate such a wrapper; it would be trivial, and allow you to use any synthesisable type for your ports - even records. But they aren't... - Brian
From: KJ on 17 Jan 2010 19:04 > Well just your description is significanly longer than the buttons > to generate the testbench in ISE. OK, so I ramble on a bit... > It's actually more of a > timesaver if you use Verilog, where the instantiation and > wires / regs don't resemble the source code like in VHDL. Yeah, VHDL is better than Verilog any day of the week ;) > This goes > doubly for a beginner, who may not know the basics > required to start the testbench. > Not sure the beginer learns much just by clicking on a button though. > Just my 2 cents, I'll see your 2 cents, and raise you a penny KJ
From: KJ on 17 Jan 2010 19:49 > In the end, > it more a matter of preference than anything. If you like the format > of your code using Booleans, go ahead. There are no real roadblocks > to using them. > In the end, the main advantage of std_logic is with unknowns. Booleans will initialize themselves to 'False', std_logic to 'U'. Proving that your design does not depend on a lucky initialization value happens when you use std_logic not booleans. Kevin Jennings
From: Gabor on 18 Jan 2010 08:49 On Jan 17, 7:49 pm, KJ <kkjenni...(a)sbcglobal.net> wrote: > > In the end, > > it more a matter of preference than anything. If you like the format > > of your code using Booleans, go ahead. There are no real roadblocks > > to using them. > > In the end, the main advantage of std_logic is with unknowns. > Booleans will initialize themselves to 'False', std_logic to 'U'. > Proving that your design does not depend on a lucky initialization > value happens when you use std_logic not booleans. > > Kevin Jennings Interestingly enough, for FPGA synthesis, the boolean will more closely resemble the final hardware. "Uninitialized" logic in an FPGA generally defaults to zero, at least for Xilinx XST. There may be some architectures that don't initialize every register and memory bit in the configuration bitstream, but I haven't run across them yet. Regards, Gabor
From: KJ on 18 Jan 2010 09:45 On Jan 18, 8:49 am, Gabor <ga...(a)alacron.com> wrote: > On Jan 17, 7:49 pm, KJ <kkjenni...(a)sbcglobal.net> wrote: > > > > In the end, > > > it more a matter of preference than anything. If you like the format > > > of your code using Booleans, go ahead. There are no real roadblocks > > > to using them. > > > In the end, the main advantage of std_logic is with unknowns. > > Booleans will initialize themselves to 'False', std_logic to 'U'. > > Proving that your design does not depend on a lucky initialization > > value happens when you use std_logic not booleans. > > > Kevin Jennings > > Interestingly enough, for FPGA synthesis, the boolean will > more closely resemble the final hardware. "Uninitialized" > logic in an FPGA generally defaults to zero And when that first clock cycle comes along right after configuration that nicely initialized value of zero is overwritten...and that first clock edge happens to violate the setup time of the flop(s)...and you use that flop in a feedback path (like a state machine) and you neglected to add a reset term...well, you might well appreciate the value of an 'X' in simulation after all While it's true that boolean more closely models reality in that real digital logic only has two values, the reality is that the tools and data types are abstractions to help one engineer a robust design. Things that assist in finding design errors earlier are a good thing. Kevin Jennings
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: CPLD programming sequence XC9500 Next: Which WebPack for old Spartan and Spartan-2? |