Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Re: Mixed clocked/combinatorial coding styles

Reply
Thread Tools

Re: Mixed clocked/combinatorial coding styles

 
 
KJ
Guest
Posts: n/a
 
      08-23-2008

"rickman" <(E-Mail Removed)> wrote in message news:99d6d66f-322e-4bce-98a3-
> In fact, I was under the impression that
> there is no "standard" for what parts of the language were supported
> for synthesis. Am I wrong about this?


IEEE 1076.6

http://www.google.com/search?hl=en&q=vhdl+1076.6

KJ


 
Reply With Quote
 
 
 
 
Paul Taylor
Guest
Posts: n/a
 
      08-23-2008
On Fri, 22 Aug 2008 14:15:29 +0100, Martin Thompson wrote:

> I've never seen a variable-related bug in my time. In the old days
> there we *limitations*, but I haven't come across any of those
> recently either in the tools I use. And I use a *lot* of variables
> (and records, and procedures within processes, and all sorts of other
> things that didn't used to work, but make my life easier *now*).
>
> YMMV however


That's interesting. I did some Xilinx work recently, and reluctantly had
to change my code. I used variables for the sake of 'localization' - the
Xilinx simulator simulated it correctly, but XST gave me some warnings and
indeed when I scoped related outputs from the FPGA, some of the logic
related to the variables had been removed in line with the warnings.

My variable use was pretty simple - slv set in an async reset block and at
the end of the clocked part of the process, and used only in the clocked
part. I couldn't see anything wrong with it, and neither could the
simulator.

Regards,

Paul.
 
Reply With Quote
 
 
 
 
Paul Taylor
Guest
Posts: n/a
 
      08-23-2008
On Fri, 22 Aug 2008 05:39:40 -0700, rickman wrote:

> Not to mention poorly supported compared to signals, both in
> simulation and synthesis. If you use variables, you will see more
> bugs and limitations of the tools. Why? I guess because it is just
> not as mainstream. Kinda like driving a Maserati for the daily
> commute.


If the tools don't support variables then I find that rather frustrating,
and using your car analogy, consider them old skoda style.

Regards,

Paul.
 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      08-23-2008
Paul Taylor wrote:

> That's interesting. I did some Xilinx work recently, and reluctantly had
> to change my code. I used variables for the sake of 'localization' - the
> Xilinx simulator simulated it correctly, but XST gave me some warnings and
> indeed when I scoped related outputs from the FPGA, some of the logic
> related to the variables had been removed in line with the warnings.


Post the code and I'll have a look.
Did you miss a port assignment?
There are many reasons that synthesis may remove logic
and none that I know of have to do with variables vs signals.
My examples here:
http://mysite.verizon.net/miketreseler/
use variables exclusively, and work fine with xst.

-- Mike Treseler
 
Reply With Quote
 
Paul Taylor
Guest
Posts: n/a
 
      08-23-2008
On Sat, 23 Aug 2008 08:44:32 -0700, Mike Treseler wrote:

> Paul Taylor wrote:
>
>> That's interesting. I did some Xilinx work recently, and reluctantly had
>> to change my code. I used variables for the sake of 'localization' - the
>> Xilinx simulator simulated it correctly, but XST gave me some warnings and
>> indeed when I scoped related outputs from the FPGA, some of the logic
>> related to the variables had been removed in line with the warnings.

>
> Post the code and I'll have a look.
> Did you miss a port assignment?
> There are many reasons that synthesis may remove logic
> and none that I know of have to do with variables vs signals.
> My examples here:
> http://mysite.verizon.net/miketreseler/
> use variables exclusively, and work fine with xst.


I'll have access to the code again next week - I'll have another look at
it and post it.

Thanks,

Paul.
 
Reply With Quote
 
Kim Enkovaara
Guest
Posts: n/a
 
      08-25-2008
rickman wrote:
>> Of course with FPGAs also initial values can be used and then no reset
>> is connected to the FF. The initial value comes from the configuration
>> file in that case.

>
> But this requires the global set reset signal. That is how the FFs
> get their initial state.


No it does not. The FF state is set via the SRAM configuration cells
during the chip powerup.

>> Not always. You can also use the FFs without any reset and give initial
>> values for the signals. Most synthesizers can transfer those values
>> to configuration image.

>
> I don't think this is the rule. If you want to write portable code,
> you need to use a reset as part of the clocked process.


For portable code that works also with ASICs the reset signal is almost
mandatory. But for pure FPGAs the initial values can be used, and
for fast designs they save routing resources.

And and least Synplify supports initial values in signals and memories,
if the used FPGA also supports them. And most of the FPGA families
support setting of the initial value of FF, and also in many families
the memory contents can be set to predefined values.

>> It might cause problems, because the internal global reset lines inside
>> FPGA are quite slow. And the signal might not propagate trough the FPGA
>>...

> Maybe if you are running at 200 MHz. There are always speed issues in
> any design. That is why you use timing constraints. You do use
> timing constraints, right?


Usually if you put timing constraint to the synchronous reset it pops
out from the global line, because it is too slow. And also for multiple
clock domains reset networks in normal routing are needed. I have
sometimes asked from the FPGA manufacturers if they could build global
resets that are fast, and can be split to create many clock domains.
After that they would be more useful, single clock domain designs are
quite rare at least in telecommunication side.

--Kim
 
Reply With Quote
 
rickman
Guest
Posts: n/a
 
      08-25-2008
On Aug 25, 3:17 am, Kim Enkovaara <(E-Mail Removed)> wrote:
> rickman wrote:
> >> Of course with FPGAs also initial values can be used and then no reset
> >> is connected to the FF. The initial value comes from the configuration
> >> file in that case.

>
> > But this requires the global set reset signal. That is how the FFs
> > get their initial state.

>
> No it does not. The FF state is set via the SRAM configuration cells
> during the chip powerup.


You are confused. The FFs do not have SRAM configuration cells that
set the initial state of the FF. The configuration memory sets the
select lines on a number of multiplexers in the logic cell as well as
other control points that remain fixed throughout the life of a given
configuration. They also control the routing elements outside the
logic cell. Finally, they *are* the LUT (along with some pass
transistors) that determines the logic. But there is no configuration
ram that sets the initial state of the FFs in the logic cells of a
Xilinx, Altera or Lattice FPGA that I have seen.


> For portable code that works also with ASICs the reset signal is almost
> mandatory. But for pure FPGAs the initial values can be used, and
> for fast designs they save routing resources.


The routing resource for the global set/reset is dedicated and can't
be used for any other purpose. Why? Because it is *always* used by
the GSR whether or not you decide to control its use.


> And and least Synplify supports initial values in signals and memories,
> if the used FPGA also supports them. And most of the FPGA families
> support setting of the initial value of FF, and also in many families
> the memory contents can be set to predefined values.


That may be true. But until it becomes a standard that is followed by
all vendors, you can't count on it when you write your code, unless
you don't care about portability. I sometimes write non-portable
code. But I try to limit it small, application specific code sections
that are well documented and easy to replace when doing a port. But
to toss the global set/reset would require a major rewrite if you need
to add it back at any time because you switched tools.


> Usually if you put timing constraint to the synchronous reset it pops
> out from the global line, because it is too slow. And also for multiple
> clock domains reset networks in normal routing are needed. I have
> sometimes asked from the FPGA manufacturers if they could build global
> resets that are fast, and can be split to create many clock domains.
> After that they would be more useful, single clock domain designs are
> quite rare at least in telecommunication side.


That may be true for designs at very high speed, but actually a sync
reset can be distributed on a clock line which should do the job quite
nicely.

The main point is that one of us has a misunderstanding of how a logic
cell FF gets it's initial state. I think this is fundamental to the
discussion. I am pretty confident that I am correct, but if you know
I am wrong, I would like to know that. I would feel like a fool if I
were having this discussion with a customer and turned out to be
wrong. I much prefer to find out now.

Rick
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      08-25-2008
On Aug 22, 7:55 am, rickman <(E-Mail Removed)> wrote:
> Well, that makes sense. If you are used to writing software, then you
> will be more comfortable with variables. I have a much stronger
> hardware background. I design my hardware in block diagrams, tables
> and state charts before I write any code (if needed). I then write
> the code that describes the registers and logic. I take the D in HDL
> literally (hardware Description language) and use the language to
> describe the hardware I want. I actually did not get a job offer
> once because I said that I code RTL. One of the lead engineers felt
> very strongly that this was too inefficient to be effective and
> blackballed an offer. Funny, I seem to be doing just fine on the
> engineering side of things. I wish I had a business manager though.



SW vs HW orientation as a preference motivation makes sense to me
also. I have more background in HW design than in SW, but when it
comes to executable language based descriptions (HDL), I guess I now
emphasize the L(anguage) part more. I started out coding HDL like I
used to draw schematics (this is a register, that is the gates, etc.),
but saw very limited benefit to using the language that way. I can
place and wire up a schematic symbol for a register faster than I can
type it's inference. The ability to describe more complex things like
state machines etc. was much easier in HDL though, especially when I
learned that you can infer the register for free in the same process.
From there I gradually adopted a more "software-like" approach to RTL
coding. I also took a couple of ada programming courses to gain some
knowledge in the use of packages, procedures, functions, etc. That's
where I started learning about using scoping rules to isolate an
implementation from its interface, at various levels of design. I
started out using all that stuff (including variables) in test
benches, then gradually started using it in RTL code (perhaps a bit of
a misnomer).

Mike's example is a very good one because it demonstrates that you can
take advantage of the immediate update behavior of variables to do
things that would be more difficult in signals. Your counter-example
of using a concurrent assignment is functionally valid, but I prefer
not to hop out of a sequential process, into a concurrent statement,
and then back to the process when I can use a variable to do the same
thing without changing contexts. Another benefit occurs when the
device driver writer and I are in the lab, integrating his SW with my
HW. Having an HDL coding style that both of us can understand is very
handy (I could already understand his programming language). I lost
count of how many times I used to have to explain that sequential code
(processes) using signals is only partially sequential, the updates
still happen concurrently. Perhaps that's another reason why the HW
approach to HDL coding makes more sense to some users: that's the only
way you can really make sense of signals in clocked processes (by
mentally mapping them to registers), they sure don't make sense
functionally to me.

I use Synplify almost exclusively, and it is very good with variables.
The times I've tried XST (admittedly somewhat in the past), I did not
appreciate its relative inflexibility, and usually got better results
from Synplify anyway.

Andy
 
Reply With Quote
 
KJ
Guest
Posts: n/a
 
      08-25-2008
On Aug 25, 1:08*pm, rickman <(E-Mail Removed)> wrote:
> On Aug 25, 3:17 am, Kim Enkovaara <(E-Mail Removed)> wrote:
>
> > rickman wrote:
> > >> Of course with FPGAs also initial values can be used and then no reset
> > >> is connected to the FF. The initial value comes from the configuration
> > >> file in that case.

>
> > > But this requires the global set reset signal. *That is how the FFs
> > > get their initial state.

>
> > No it does not. The FF state is set via the SRAM configuration cells
> > during the chip powerup.

>
> You are confused. *The FFs do not have SRAM configuration cells that
> set the initial state of the FF. *


Kim said the 'configuration file' not 'SRAM configuration cells',
there is a difference.

> The configuration memory sets the
> select lines on a number of multiplexers in the logic cell as well as
> other control points that remain fixed throughout the life of a given
> configuration. *They also control the routing elements outside the
> logic cell. *Finally, they *are* the LUT (along with some pass
> transistors) that determines the logic. *But there is no configuration
> ram that sets the initial state of the FFs in the logic cells of a
> Xilinx, Altera or Lattice FPGA that I have seen.
>


There might not be a 'configuration ram' (as you call it), but there
are bits in the bitstream in the 'configuration file' (as Kim calls
it) that are a part of the data set that gets downloaded to the device
to implement the initial values. At leasst with Altera devices, this
all gets done without any 'global set/reset' signals, the only signals
needed are the ones needed to download the bitstream file. Once the
device configuration process has been completed, those initial values
are there.

Lastly, I might add that there may not even be specific bits in the
bitstream to say that flip flop #235 which happens to hold signal
'xyz' needs to be initialized to '1'. Instead the logic can be
implemented in such a fashion that the device, when it finishes
configuration and is begining initialization *prior* to coming alive
and being in user mode (i.e the chip at this point isn't totally alive
yet running your design) that all the flip flops simply get reset. In
that type of situation, the code would implement negative logic for
signal 'xyz' and then wherever 'xyz' is used, it would invert it
again. This double inversion is a fairly common way to implement
arbitrary power up states and since invertors are 'free' inside an
FPGA it is a very cost effective way as well.

For a discussion of Altera Cyclone II devices refer to
http://www.altera.com/literature/hb/..._cii5v1_06.pdf

They don't specifically say *how* they get things into the proper
initialization state but
- They do initialize memory and flip flops
- No special pins are needed (just the pins used to download the
bitstream). Spcifically there is no need for a 'GSR'.
- User specified default values for memory and flops are honored.

> > And and least Synplify supports initial values in signals and memories,
> > if the used FPGA also supports them. And most of the FPGA families
> > support setting of the initial value of FF, and also in many families
> > the memory contents can be set to predefined values.

>
> That may be true. *But until it becomes a standard that is followed by
> all vendors, you can't count on it when you write your code, unless
> you don't care about portability. *


It is already is a standard (i.e. the VHDL language says so). Although
I haven't looked to see if it is part of the synthesis subset in IEEE
1076.6. even if it is not, once some of the competition supports
something that gives the users of the laggard tools some ammo to have
them get their tools up to date. What tool are you using that does
not support it? Perhaps you should consider opening a case with
them. After all, there aren't that many synthesis tools out there,
opening a case can get results...maybe not when you need it 'today',
but at least by the time you need it down the road. That improves the
tools for everyone.

> That may be true for designs at very high speed, but actually a sync
> reset can be distributed on a clock line which should do the job quite
> nicely.
>
> The main point is that one of us has a misunderstanding of how a logic
> cell FF gets it's initial state. *I think this is fundamental to the
> discussion. *I am pretty confident that I am correct, but if you know
> I am wrong, I would like to know that. *I would feel like a fool if I
> were having this discussion with a customer and turned out to be
> wrong. *I much prefer to find out now.
>


I think the method by which initial values get loaded could be a
device specific discussion that the vendors may not fully disclose.

I will say that for the devices I've been using I do not need to use
the asynchronous reset form of a process or have any GSR signal to get
initial values loaded. Those initial values specified in the source
code get turned into a bitstream that when downloaded to the device
does seem to work...and when it doesn't I open a case with the
supplier.

But as I mentioned a while back, about the only time I actually *use*
initial values or async resets at all is to for the shift register(s)
used to generate the reset signal(s) that are synchronized to the
various clock(s)...and I can do it all without need for any external I/
O pin to initiate that reset.

KJ
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      08-25-2008
On Aug 25, 12:08 pm, rickman <(E-Mail Removed)> wrote:
> On Aug 25, 3:17 am, Kim Enkovaara <(E-Mail Removed)> wrote:
>
> > rickman wrote:
> > >> Of course with FPGAs also initial values can be used and then no reset
> > >> is connected to the FF. The initial value comes from the configuration
> > >> file in that case.

>
> > > But this requires the global set reset signal. That is how the FFs
> > > get their initial state.

>
> > No it does not. The FF state is set via the SRAM configuration cells
> > during the chip powerup.

>
> You are confused. The FFs do not have SRAM configuration cells that
> set the initial state of the FF. The configuration memory sets the
> select lines on a number of multiplexers in the logic cell as well as
> other control points that remain fixed throughout the life of a given
> configuration. They also control the routing elements outside the
> logic cell. Finally, they *are* the LUT (along with some pass
> transistors) that determines the logic. But there is no configuration
> ram that sets the initial state of the FFs in the logic cells of a
> Xilinx, Altera or Lattice FPGA that I have seen.
>
> > For portable code that works also with ASICs the reset signal is almost
> > mandatory. But for pure FPGAs the initial values can be used, and
> > for fast designs they save routing resources.

>
> The routing resource for the global set/reset is dedicated and can't
> be used for any other purpose. Why? Because it is *always* used by
> the GSR whether or not you decide to control its use.
>
> > And and least Synplify supports initial values in signals and memories,
> > if the used FPGA also supports them. And most of the FPGA families
> > support setting of the initial value of FF, and also in many families
> > the memory contents can be set to predefined values.

>
> That may be true. But until it becomes a standard that is followed by
> all vendors, you can't count on it when you write your code, unless
> you don't care about portability. I sometimes write non-portable
> code. But I try to limit it small, application specific code sections
> that are well documented and easy to replace when doing a port. But
> to toss the global set/reset would require a major rewrite if you need
> to add it back at any time because you switched tools.
>
> > Usually if you put timing constraint to the synchronous reset it pops
> > out from the global line, because it is too slow. And also for multiple
> > clock domains reset networks in normal routing are needed. I have
> > sometimes asked from the FPGA manufacturers if they could build global
> > resets that are fast, and can be split to create many clock domains.
> > After that they would be more useful, single clock domain designs are
> > quite rare at least in telecommunication side.

>
> That may be true for designs at very high speed, but actually a sync
> reset can be distributed on a clock line which should do the job quite
> nicely.
>
> The main point is that one of us has a misunderstanding of how a logic
> cell FF gets it's initial state. I think this is fundamental to the
> discussion. I am pretty confident that I am correct, but if you know
> I am wrong, I would like to know that. I would feel like a fool if I
> were having this discussion with a customer and turned out to be
> wrong. I much prefer to find out now.
>
> Rick


To be precise, at least in Xilinx FPGAs, there is a configuration bit
that determines whether the GSR signal will reset or preset the
associated register(s). The GSR signal is asserted during and until
shortly after configuration. The GSR signal is what activates the set/
preset, but the configuration bit determines the initial state of the
register.

The application of a "synchronized asynchronous" reset (asynchronous
assertion and reset/preset operation, synchronous deassertion and
resumption of clocked operation) for multiple clock domains requires
multiple reset signals, each one appropriately synchronized to the
destination clock.

The GSR and such locally synchronized reset signals are logically
OR'ed at each CLB. The GSR block used to allow synchronization of GSR
to a single user clock, but I'm not sure if it still does, or if
synthesis tools typically implement it that way, since the propagation
delay on the GSR net is very slow.

I can personally attest that asynchronous reset synchronization is
most certainly NOT a red herring!

Andy
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
typedef a struct [C Coding styles] MJ_India C Programming 5 10-10-2008 12:53 PM
Mixed clocked/combinatorial coding styles (another thread) whygee VHDL 23 08-26-2008 03:28 PM
Re: Mixed clocked/combinatorial coding styles Mike Treseler VHDL 0 08-19-2008 06:18 AM
Re: Mixed clocked/combinatorial coding styles kennheinrich@sympatico.ca VHDL 0 08-18-2008 05:46 PM
C Coding Styles and the use of Macros davej C Programming 5 11-21-2003 04:38 PM



Advertisments