Verilog style question

Hi, all,

I'm writing my first bit of mildly nontrivial Verilog. It's a controller for a sort of combination boxcar and lock-in, with a few bells and whistles. (The lock-in runs for exactly N cycles, with nonoverlapping switch waveforms with enough dead zone for the amps to settle, and then holds the final value.)

To make the control inputs well-behaved, I'd like to make them ones-catching, i.e. clock 1 into a register when they arrive, and reset it when a state machine gets to the right point.

So I had a bunch of things like this:

always@(posedge reset) resetLatch

Reply to
Phil Hobbs
Loading thread data ...

Den fredag den 11. april 2014 21.45.26 UTC+2 skrev Phil Hobbs:

VHDL wouldn't help you

it's hard to tell exactly what you want to do but;

you should generally register your inputs through a FFs or two before you use them to avoid(reduce) the risk of meta-stabilty sending your state machine to lala-land

you should think about what hardware you have, a ff with clk and rst it can't be sensitive to the edges of more than two signals

can your "Go" signal be less that a clk cycle wide?

-Lasse

Reply to
Lasse Langwadt Christensen

I'm no expert, but: from my Verilog book:

always @(posedge clock or negedge reset) begin if (~reset) currentState

Reply to
Tim Wescott

Thanks.

There do seem to be some weird restrictions that don't relate to the hardware, too:

For instance, inside an always block, it pukes on

somereg

Reply to
Phil Hobbs

In some situations, probably.

Thanks

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

The whole register it with FF thing helps with metastability: you basically clock the input through a short shift register; if the input is at half-mast when the clock happens, then by the time it gets through a couple of flip flops (so the theory goes) it has resolved into a firm zero or one, and you don't end up with a bunch of bits that are hanging in the middle somewhere.

Xilix et all deny the possibility that metastability could be a problem with their parts. Nearly everyone that I know who does FPGA design uses the chain-o-ff trick. Pick your poison.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

I've used that in the past, both in MSI and in the DOS Orcad PLD tools. It's really that I'm just learning Verilog, and don't know the syntax quirks very well yet. Xilinx's cryptic error messages aren't much help.

Thanks

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

do you want it to trigger only once per rising edge?

retrigger if you get an new edge before your state machine reach clear?

I can quickly whip something up if if you have a bit more info

-Lasse

Reply to
Lasse Langwadt Christensen

what is the error?

it should be the same and both valid

-Lasse

Reply to
Lasse Langwadt Christensen

Sounds analogous to the syntax differences between VHDL's combinatorial _architecture_ block, and the _process_ block that can go within. You can do the same things with the same signals, but the latter is written as a procedural conditional (which makes edge triggered logic possible, or at least, easier).

Something else that would be tempting might be a dual-clocked FF (like PC3 in the... HC4046 or 7046??), which could be described as:

process (clk1, clk2) begin if (clk1'event and clk1='1') then q = '1'; elsif (clk2'event and clk2='1') then q = '0'; end if; end process;

But most (all?) tools will not synthesize this due to the dual edge dependency.

You have to work around such situations by describing the combinatorial logic yourself (two D's and an RS, for example). Which will of course be much slower than a single cell synthesis (assuming they provided dual clocked FFs in the standard cells).

Afraid I only have experience in VHDL, so if this was helpful at all, I don't know. :p

Tim

--
Seven Transistor Labs 
Electrical Engineering Consultation 
 Click to see the full signature
Reply to
Tim Williams

afaiu the Xilinx point is that the FFs are so fast that it is extremely rare a FF will take longer to resolve metastability than any realistic clock

So the output of FF will have resolved to a firm 0/1 long before the next clock edge, so FFs after that first FF will "never" see anything but a firm 0/1 with plenty of setup time

-Lasse

Reply to
Lasse Langwadt Christensen

It is not metastability that is the problem. It is the possibility of a signal changing at some random time relative to your clock. In a state machine, an external signal can decide whether you go to state 21 or 22 when in some particular state. If that input were to change such that some of the state registers got the new value and some the old because the change was within the setup time for those FFs, you could end up being thrown into some random state. If a one-hot state machine, you could end up with multiple bits set. On a binary coded state machine, you could just end up in an odd state.

The timing tools will guarantee that anything clocked internally will satisfy setup and hold times on every FF on the chip, so when some signal changes, it guarantees that ALL FFs that need that signal will get the same value. But, when an un-synchronized input comes in, the tools can't handle that.

Now, if you can demonstrate your logic fails with a SINGLE rank FF on the inputs, but runs reliably with DUAL rank FFs, then it sounds like metastability. But, NO FFs on inputs going into anything clocked is pure trouble.

Jon

Reply to
Jon Elson

Thanks. I wound up doing this:

always@(posedge fastclk) begin GoBuf[1]

Reply to
Phil Hobbs

much better, once you skip all the async edge triggered stuff and run everything on a single clock it is much easier to prove that it works

yeh, sometimes the resemblance to C can trick people to think that it is a programming language like C. It is not, it is a hardware description language and if you want it to be synthesisable you need to describe something that is realizable in the available hardware

-Lasse

Reply to
Lasse Langwadt Christensen

Those two chunks of code aren't equivalent though, if any of varx are vectors rather than single bits.

if (var) ...

is a boolean test, equivalent to the C boolean tests: if all bits of the the argument (var) are zeros, it's false, otherwise true.

The "bar" operator | is a bit-by-bit or. It returns a vector of bits, with length equal the maximum length of its arguments. Each bit of the result is equal to the or of the corresponding bits of the inputs. (If any of the inputs is short, it is zero extended on the left.) If you then assign this to a single bit variable, it will throw away all but the least significant bit of the result. (This happens silently, and can cause hard to find bugs.)

The || operator is a boolean or. If either argument is true (i.e. contains any 1 bits) it will return true (a single 1).

I suggest you read up on the differences between:

~ (bitwise not) and ! (boolean not) & (bitwise and) and && (boolean and) | (bitwise or) and || (boolean or)

Whist I don't think this has anything to do with the tool "puke" problem, it is something that is important to understand when starting with Verilog.

Regards, Allan

Reply to
Allan Herriman

Sacrilege, we're electronics engineers here...

Kevin Aylward B.Sc.

formatting link
formatting link
- SuperSpice

Reply to
Kevin Aylward

Thanks. The distinction is the same as in C, so it's very familiar. In this case they're all scalars, so bitwise and logical ought to be equivalent.

The ISE tool says that the feature is unimplemented.

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs 
Principal Consultant 
 Click to see the full signature
Reply to
Phil Hobbs

Hi Phil,

I would be very surprised if XST couldn't handle that statement. I suspect that there's more going on in your source code that can be determined from your post.

Also, XST is a family of compilers. Different parsers are used depending on the target device and the ISE version.

So...

Are you able to post a larger chunk of source code?

What is the exact error message?

Could you identify the target device?

What is the ISE version?

What do tools other than XST say about the code? I always simulate in Modelsim before letting the (relatively braindead) Xilinx tools see the code. In general synthesisers (e.g. XST) interpret the language reference manual rather loosely, and simulators (particularly the "big

3") stick quite closely to the LRM.

BTW, this code:

module foo ( input wire var1, input wire var2, input wire var3, output reg somereg );

always @(*) begin somereg

Reply to
Allan Herriman

Differences between e.g. C lang and Verilog statements. there are no clean rules broken with that style ... as long as you know exactly what you are doing.

H
Reply to
Habib Bouaziz-Viallet

It has a state machine already, for something else. I solved it by moving the goal posts--the asynchronous signals have to be valid long enough to include a rising clock edge, rather than using ones-catching inputs. Then they go into a 3-stage shift register,

always@(posedge fastclk) begin GoBuf[2]

Reply to
Phil Hobbs

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.