Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 143850

Article: 143850
Subject: Re: Best way to model a large external ROM in a simulation? (XST
From: TSMGrizzly <sbattazz@yahoo.co.jp>
Date: Thu, 29 Oct 2009 07:29:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 29, 10:45=A0pm, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
>
> Seconded. If you need to read files created by other tools (e.g. a spread=
sheet,
> or a binary file like a .bmp) this is a reasonable way to do it, and more
> flexible than the above approach. However ISE Simulator has some
> not-well-documented obstacles(*) to reading binary files, which is more
> straightforward in Modelsim.
>
> (*) As of ISE10:
> a) it is opposite-endian to Modelsim's treatment of the same file.
> b) ISIM writes an undocumented header before the file contents, and expec=
ts to
> see that header on any file it reads. You can convert a 3rd party file to=
/from
> ISIM using head, tail and cat to extract/insert the header (on Linux, or =
the
> Windows equivalent commands) but it's a bother.
> c) =A0Xilinx have declined to document this header. However there is a Ch=
ange
> Request to fix these issues; I have no idea if/when it will happen.
>
> - Brian

Thanks Brian, good to know. Thankfully I can probably get away with
not using binary files for input.

I am on Linux and we don't have funding at the moment for stuff like
Modelsim licenses, so I'm pretty much bound to the ISE simulator for
now. I know Modelsim is smoother and nicer, but they were not nice
enough to make Modelsim XE for Linux :(

I'll just make the big array of constants, and rewrite the file
whenever I need to make changes to it.

Article: 143851
Subject: Re: error while opening hex file
From: d_s_klein <d_s_klein@yahoo.com>
Date: Thu, 29 Oct 2009 08:51:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 29, 6:47=A0am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Thu, 29 Oct 2009 06:22:33 -0500, "zss" <zarit...@yahoo.com> wrote:
> >Hi, I'm designing using ROM and hex file.I'm new at using this.
> >I've created this .hex file for the ROM and everytime I close the quartu=
s
> >window and open the hex file again to edit it, it says
>
> >"cant open file -- file contains ni memory cell values"..??
>
> >what I did wrong?help
>
> You may need to build a shrubbery.
>
> - Brian

Perhaps this will help:
<http://wiki.answers.com/Q/How_do_you_cut_down_a_tree_with_a_herring>

Article: 143852
Subject: Re: Trouble in booting V5 FPGA from SPI flash.
From: John Adair <g1@enterpoint.co.uk>
Date: Thu, 29 Oct 2009 10:57:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
Have you checked that your DONE signal has gone high thereby releasing
the chip out of config and into operation. Use the JTAG to do a status
read if you don't have access to the signal.

John Adair
Enterpoint Ltd. - Home of Merrick1. The ASIC Prototype Platform.


On 29 Oct, 10:39, crescent <hanpei...@gmail.com> wrote:
> Hi all,
> I am now using an Atmel AT45DB321D SPI flash booting xc5vsx50t-ff1136
> and there is something wrong. First, the FPGA can be programmed
> successfully, and the flash also can be programmed successfully both
> directly & indirectly via iMPACT. But the FPGA just can't boot from
> the flash. I checked the timing diagram of the signals: PROG_B,
> INIT_B, M[2:0], FS[2:0], FCS_B, CCLK, MOSI, DIN, the MOSI did not
> function right compared to the timing diagram in XAPP951 page8 (M[2:0]
> =001,FS[2:0]=111). Pin MOSI clocks out 001100000.... after FCS_B goes
> low and it should be 000010110...
> I have no idea what's wrong and what should I do to fix this. So any
> help would be thankfull!


Article: 143853
Subject: Re: Trouble in booting V5 FPGA from SPI flash.
From: crescent <hanpei369@gmail.com>
Date: Thu, 29 Oct 2009 18:29:56 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 30, 1:57=A0am, John Adair <g...@enterpoint.co.uk> wrote:
> Have you checked that your DONE signal has gone high thereby releasing
> the chip out of config and into operation. Use the JTAG to do a status
> read if you don't have access to the signal.
>
> John Adair
> Enterpoint Ltd. - Home of Merrick1. The ASIC Prototype Platform.

> - Show quoted text -

John,
Thank you for your reply. The signal DONE on my board drives a LED
through a
buffer. After FPGA successfully configured, the LED should light which
is not seen
when programming from flash. That's to say the FPGA is under
configuration all the
time.


Article: 143854
Subject: Simple state machine output question
From: TSMGrizzly <sbattazz@yahoo.co.jp>
Date: Thu, 29 Oct 2009 23:23:49 -0700 (PDT)
Links: << >>  << T >>  << A >>
In a two-process state machine with many outputs, I would like to have
a few output signals whose values would be updated and latched on
certain states, and left as they are during all other states.

Is it correct that this can be accomplished by simply not assigning
these signals with default values, and only including assignments for
them during the states where I would like them latched? Is this sound
coding practice?

Thanks,

TSM

Article: 143855
Subject: Re: Simple state machine output question
From: backhus <goouse@twinmail.de>
Date: Thu, 29 Oct 2009 23:37:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On 30 Okt., 07:23, TSMGrizzly <sbatt...@yahoo.co.jp> wrote:
> In a two-process state machine with many outputs, I would like to have
> a few output signals whose values would be updated and latched on
> certain states, and left as they are during all other states.
>
> Is it correct that this can be accomplished by simply not assigning
> these signals with default values, and only including assignments for
> them during the states where I would like them latched? Is this sound
> coding practice?
>
> Thanks,
>
> TSM

Hi,
don't say "latched" here, with FPGAs we all want signals to be
registered. ;-)

And so, if your outputs are set in a registered process you can set
them once and they keep that value as long as they are unchanged.
But it's quite difficult do achieve with a standard two process FSM,
where branches and outputs are handled in a combinatorical process.
Ugly.
In the past I favoured three process FSMs, but now I'm doing it in one
process, where the state is stored in a variable (and the state type
defined inside the process).

Have a nice synthesis
  Eilert



Article: 143856
Subject: Re: Best way to model a large external ROM in a simulation? (XST simulator)
From: "RCIngham" <robert.ingham@gmail.com>
Date: Fri, 30 Oct 2009 06:10:53 -0500
Links: << >>  << T >>  << A >>
<snip>
>
>I'll just make the big array of constants, and rewrite the file
>whenever I need to make changes to it.
>

If your ROM is *really* big (> 1M locations) you may run into simulator
difficulties if you define the contents as an array of std_logic_vector.
Defining it as an array of integer is most memory-efficient, but you have
to convert it to signed/unsigned and cast to std_logic_vector to drive the
port.
An array of bit_vector is 2nd best.
	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Article: 143857
Subject: Re: Simple state machine output question
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 30 Oct 2009 04:16:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 30, 2:23=A0am, TSMGrizzly <sbatt...@yahoo.co.jp> wrote:
> In a two-process state machine with many outputs, I would like to have
> a few output signals whose values would be updated and latched on
> certain states, and left as they are during all other states.
>
> Is it correct that this can be accomplished by simply not assigning
> these signals with default values, and only including assignments for
> them during the states where I would like them latched?

No.  Think for a minute about it.  You've got some output that is
coming out of a flip flop.  If you don't want it to change values then
you make the default assignment to assign that output to the value
currently in the output of the flop.

> Is this sound coding practice?
>
The unsound practice is using an unclocked process which then implies
that it is unsound to use a two process model.  Processes with a
sensitivity list that consist of more than just 'clock' are prone to
creating design problems that are just not possible when written as a
single clocked process [1].

Despite what textbooks would have you believe, state machines do not
need to be coded as two processes.

KJ

[1] The problems with an unclocked process are:
- Must insure that there is an assignment to every signal on every
path through the process or a latch will be created which is a design
problem that will need to then be fixed...after having to debug to
find the problem.  Typically this is accomplished by assigning default
values at the begining of the process
- Must insure that the sensitivity list is complete or the synthesized
result will not match the code as written and interpreted by the
simulator.
- The default assignments are extra code that is not needed if written
as a single process instead....it's your time.

Article: 143858
Subject: Re: Trouble in booting V5 FPGA from SPI flash.
From: John Adair <g1@enterpoint.co.uk>
Date: Fri, 30 Oct 2009 04:38:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
Did you buffer the drive to the LED. If not this a common issue for
DONE not making the correct logic level. Double check with the JTAG
status to be sure.

John Adair
Enterpoint Ltd.


On 30 Oct, 01:29, crescent <hanpei...@gmail.com> wrote:
> On Oct 30, 1:57=A0am, John Adair <g...@enterpoint.co.uk> wrote:
>
> > Have you checked that your DONE signal has gone high thereby releasing
> > the chip out of config and into operation. Use the JTAG to do a status
> > read if you don't have access to the signal.
>
> > John Adair
> > Enterpoint Ltd. - Home of Merrick1. The ASIC Prototype Platform.
> > - Show quoted text -
>
> John,
> Thank you for your reply. The signal DONE on my board drives a LED
> through a
> buffer. After FPGA successfully configured, the LED should light which
> is not seen
> when programming from flash. That's to say the FPGA is under
> configuration all the
> time.


Article: 143859
Subject: Re: Best way to model a large external ROM in a simulation? (XST
From: Ben Jones <benjjuk@gmail.com>
Date: Fri, 30 Oct 2009 05:59:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 30, 11:10=A0am, "RCIngham" <robert.ing...@gmail.com> wrote:
> <snip>
> If your ROM is *really* big (> 1M locations) you may run into simulator
> difficulties if you define the contents as an array of std_logic_vector.
> Defining it as an array of integer is most memory-efficient, but you have
> to convert it to signed/unsigned and cast to std_logic_vector to drive th=
e
> port.

Danger, Will Robinson!

I note that your ROM table is going to contain 32-bit data. Please do
not forget that a VHDL "integer" value does not, repeat NOT,
correspond to a 32-bit two's complement integer! The "standard"
package, last time I checked, contained the immortal line:

  type INTEGER is range -2147483647 to 2147483647;

-2147483648, or 2^-31 or 0x80000000, is not, repeat NOT, a valid
integer in VHDL! If there is a possibility that your ROM will contain
this most-negative value then you must check whether your simulator
actually allows it. It probably won't. Of course, if you were hoping
for 32-bit unsigned values in your ROM then that won't fit in an
integer either, for the same reason.

To be honest, a big array of std_logic_vector won't hurt *that* much:

  subtype my_rom_data is std_logic_vector(31 downto 0);
  type my_rom_type is array(0 to 65535) of my_rom_data;

 But I recommend you define it as a constant or a variable, and never
as a signal:

  signal x : my_rom_type :=3D (...);  -- Noooo!

...because that will really slow everything down.

Cheers,

       -Ben-

Article: 143860
Subject: Re: Simple state machine output question
From: Gabor <gabor@alacron.com>
Date: Fri, 30 Oct 2009 06:25:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 30, 7:16=A0am, KJ <kkjenni...@sbcglobal.net> wrote:
> On Oct 30, 2:23=A0am, TSMGrizzly <sbatt...@yahoo.co.jp> wrote:
>
> > In a two-process state machine with many outputs, I would like to have
> > a few output signals whose values would be updated and latched on
> > certain states, and left as they are during all other states.
>
> > Is it correct that this can be accomplished by simply not assigning
> > these signals with default values, and only including assignments for
> > them during the states where I would like them latched?
>
> No. =A0Think for a minute about it. =A0You've got some output that is
> coming out of a flip flop. =A0If you don't want it to change values then
> you make the default assignment to assign that output to the value
> currently in the output of the flop.
>
> > Is this sound coding practice?
>
> The unsound practice is using an unclocked process which then implies
> that it is unsound to use a two process model. =A0Processes with a
> sensitivity list that consist of more than just 'clock' are prone to
> creating design problems that are just not possible when written as a
> single clocked process [1].
>
> Despite what textbooks would have you believe, state machines do not
> need to be coded as two processes.
>
> KJ
>
> [1] The problems with an unclocked process are:
> - Must insure that there is an assignment to every signal on every
> path through the process or a latch will be created which is a design
> problem that will need to then be fixed...after having to debug to
> find the problem. =A0Typically this is accomplished by assigning default
> values at the begining of the process
> - Must insure that the sensitivity list is complete or the synthesized
> result will not match the code as written and interpreted by the
> simulator.
> - The default assignments are extra code that is not needed if written
> as a single process instead....it's your time.

Well, in the unclocked process you could make default assigns
that are not to a constant but rather to the current output
of the flip-flop in the clocked process.  Then drop into the
case statement.  This is similar to what you get for "free"
in the single-clocked-process FSM.  What you lose in the
clocked-only FSM is the ability to assign outputs based on
the current state in the same process.  I don't think there's
anything inherently wrong with the two process approach as
long as you understand what you're making.  In the one-clock
FSM process you'd often end up with outputs assigned in
another process that depend on the state variable in order
to accomplish the same end.  I don't see how that's in any
way better than the two-process FSM.

Just my 2 cents,
Gabor

Article: 143861
Subject: Re: Best way to model a large external ROM in a simulation? (XST
From: Andy <jonesandy@comcast.net>
Date: Fri, 30 Oct 2009 06:50:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
You can also initialize a constant, variable, or signal with a
function call that returns the value to be used for initialization. So
if you have a simple enough algorithm for the contents to code in
vhdl, that might be a simpler way yet.

Oh, and use a constant if this is really a rom, rather than a signal,
for less overhead and better performance.

If you can use an integer (range constraints withstanding), it will be
smaller and more efficient. The VHDL LRM requires AT LEAST the range
-2147483647 to 2147483647 to be implemented for integer, but many
(most?) implementations handle the entire 32 bit two's complement
range. Check your simulator/synthesis tool's standard package
implementation, because there is no "standard" standard package
definition with regard to this. And if they don't implement the full
32 bit signed range, request an enhancement for them to do so.

Andy

Article: 143862
Subject: Re: Trouble in booting V5 FPGA from SPI flash.
From: Gabor <gabor@alacron.com>
Date: Fri, 30 Oct 2009 07:53:52 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 30, 7:38=A0am, John Adair <g...@enterpoint.co.uk> wrote:
> Did you buffer the drive to the LED. If not this a common issue for
> DONE not making the correct logic level. Double check with the JTAG
> status to be sure.
>
> John Adair
> Enterpoint Ltd.
>
> On 30 Oct, 01:29, crescent <hanpei...@gmail.com> wrote:
>
> > On Oct 30, 1:57=A0am, John Adair <g...@enterpoint.co.uk> wrote:
>
> > > Have you checked that your DONE signal has gone high thereby releasin=
g
> > > the chip out of config and into operation. Use the JTAG to do a statu=
s
> > > read if you don't have access to the signal.
>
> > > John Adair
> > > Enterpoint Ltd. - Home of Merrick1. The ASIC Prototype Platform.
> > > - Show quoted text -
>
> > John,
> > Thank you for your reply. The signal DONE on my board drives a LED
> > through a
> > buffer. After FPGA successfully configured, the LED should light which
> > is not seen
> > when programming from flash. That's to say the FPGA is under
> > configuration all the
> > time.
>
>

Other things to check:

1) Atmel Dataflash has a slightly different command set than
most SPI flash parts.  Be sure you have the right command
for continuous array read.

2) If you think it's a startup issue rather than loading, you
can enable the "internal Done pipe" in the bitgen options.

Regards,
Gabor

Article: 143863
Subject: Re: Simple state machine output question
From: Mike Treseler <mtreseler@gmail.com>
Date: Fri, 30 Oct 2009 08:04:08 -0700
Links: << >>  << T >>  << A >>
Gabor wrote:
> In the one-clock
> FSM process you'd often end up with outputs assigned in
> another process that depend on the state variable in order
> to accomplish the same end.  I don't see how that's in any
> way better than the two-process FSM.

I would add any logic that depends on that
state variable to the same process.

> Just my 2 cents,

Me too.

 -- Mike Treseler

Article: 143864
Subject: Re: Simple state machine output question
From: KJ <kkjennings@sbcglobal.net>
Date: Fri, 30 Oct 2009 08:06:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 30, 9:25=A0am, Gabor <ga...@alacron.com> wrote:
> On Oct 30, 7:16=A0am, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > On Oct 30, 2:23=A0am, TSMGrizzly <sbatt...@yahoo.co.jp> wrote:
>
> > > In a two-process state machine with many outputs, I would like to hav=
e
> > > a few output signals whose values would be updated and latched on
> > > certain states, and left as they are during all other states.
>
> > > Is it correct that this can be accomplished by simply not assigning
> > > these signals with default values, and only including assignments for
> > > them during the states where I would like them latched?
>
> > No. =A0Think for a minute about it. =A0You've got some output that is
> > coming out of a flip flop. =A0If you don't want it to change values the=
n
> > you make the default assignment to assign that output to the value
> > currently in the output of the flop.
>
> > > Is this sound coding practice?
>
> > The unsound practice is using an unclocked process which then implies
> > that it is unsound to use a two process model. =A0Processes with a
> > sensitivity list that consist of more than just 'clock' are prone to
> > creating design problems that are just not possible when written as a
> > single clocked process [1].
>
> > Despite what textbooks would have you believe, state machines do not
> > need to be coded as two processes.
>
> > KJ
>
> > [1] The problems with an unclocked process are:
> > - Must insure that there is an assignment to every signal on every
> > path through the process or a latch will be created which is a design
> > problem that will need to then be fixed...after having to debug to
> > find the problem. =A0Typically this is accomplished by assigning defaul=
t
> > values at the begining of the process
> > - Must insure that the sensitivity list is complete or the synthesized
> > result will not match the code as written and interpreted by the
> > simulator.
> > - The default assignments are extra code that is not needed if written
> > as a single process instead....it's your time.

>
> Well, in the unclocked process you could make default assigns
> that are not to a constant but rather to the current output
> of the flip-flop in the clocked process.

That's what I said...so I guess we agree.

> What you lose in the
> clocked-only FSM is the ability to assign outputs based on
> the current state in the same process.

Unclocked outputs that are a function of current state can be handled
with concurrent assignments.  Treseler and Andy prefer to use
variables and keep it all within the same process.

Unclocked outputs that are a function of the next state are best
handled with variables within the process.  Handling them with
concurrent assignments causes one to duplicate logic.

In any case, there is nothing lost by having only one clocked process
rather than two.

> =A0I don't think there's
> anything inherently wrong with the two process approach as
> long as you understand what you're making.

What is wrong with the two process approach is summed up in note [1]
in my previous post.  Yes, you can work around it, but doing so
requires manual eyeball verification to insure the potholes have been
missed.  Personally, I prefer a road with no potholes.

>=A0In the one-clock
> FSM process you'd often end up with outputs assigned in
> another process that depend on the state variable in order
> to accomplish the same end. =A0

One can use signals in/out of the clocked process to avoid references
to the state variable from outside the process if such references go
against your grain.

Again, the Treseler approach using variables avoids use of the state
variable from outside the process...however this is just a
technicality since his approach is to make the entire architecture one
large process.  The references to the state variable could be
scattered all over that one large process, but technically there are
no references to the state variable from outside the process.  The
distinctions only a nit-picker would love.

> I don't see how that's in any
> way better than the two-process FSM.
>

As I said in the first post, the two-process approach inherently has
an unclocked process.  The problems with an unclocked process are
defined in note [1] in that same first post.

Kevin Jennings

Article: 143865
Subject: Re: Simple state machine output question
From: Andy <jonesandy@comcast.net>
Date: Fri, 30 Oct 2009 08:26:35 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 30, 8:25=A0am, Gabor <ga...@alacron.com> wrote:
> What you lose in the
> clocked-only FSM is the ability to assign outputs based on
> the current state in the same process. =A0I don't think there's
> anything inherently wrong with the two process approach as
> long as you understand what you're making. =A0In the one-clock
> FSM process you'd often end up with outputs assigned in
> another process that depend on the state variable in order
> to accomplish the same end. =A0I don't see how that's in any
> way better than the two-process FSM.

If at all possible, I rearrange states and/or output assignments
between them to avoid comibinatorial outputs, period.

If necessary, you CAN create combinatorial outputs from the state
registers in a single, clocked process, if you use a variable for the
state:

process (clk) is -- reset omitted for brevity
  variable state : state_type;
begin
  if rising_edge(clk) then
    case state is
      when ... =3D>
         state :=3D ... ;
    end case;
  end if;
  -- combinatorial logic after state regs:
  output <=3D some_function_of(state, other_variables);
end process;

One other reason not to use combinatorial processes: simulators
optimize process overhead by merging processes with the same
sensitivity list. And since most combinatorial processes will have
unique sensitivity lists, they cannot be merged.

The use of variables is more efficient to simulate, and keeping one
process minimizes use of signals. Variables also hide the state
definitions from outside the process, making future maintenance of
them easier (less impact on other parts of the design if they could
not use your state variable in the first place).

If your synthesis tool does not accept signal assignments after the
clocked if-then-end-if, call the vendor and tell them that (at least)
Synplify and Quartus do.

Andy

Article: 143866
Subject: Re: Simple state machine output question
From: Mike Treseler <mtreseler@gmail.com>
Date: Fri, 30 Oct 2009 09:09:29 -0700
Links: << >>  << T >>  << A >>
Andy wrote:

> If at all possible, I rearrange states and/or output assignments
> between them to avoid combinatorial outputs, period.

I agree.
I like clean, synchronous interfaces between processes.

> One other reason not to use combinatorial processes: simulators
> optimize process overhead by merging processes with the same
> sensitivity list. And since most combinatorial processes will have
> unique sensitivity lists, they cannot be merged.

And if I don't limit myself to one
variable per process, my code is
already in this merged format and
easier to trace in modelsim.

  -- Mike Treseler

Article: 143867
Subject: Re: Simple state machine output question
From: Mike Treseler <mtreseler@gmail.com>
Date: Fri, 30 Oct 2009 09:43:22 -0700
Links: << >>  << T >>  << A >>
KJ wrote:

> Unclocked outputs that are a function of the next state are best
> handled with variables within the process.  Handling them with
> concurrent assignments causes one to duplicate logic.

A good point. In a clocked process,
a variable ID represents the D side of some register.
A port or signal ID represents the Q of some register.

   -- Mike Treseler

Article: 143868
Subject: Re: Simple state machine output question
From: Andy <jonesandy@comcast.net>
Date: Fri, 30 Oct 2009 11:38:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 30, 11:09=A0am, Mike Treseler <mtrese...@gmail.com> wrote:
> And if I don't limit myself to one
> variable per process, my code is
> already in this merged format and
> easier to trace in modelsim.

Simulators can merge processes with the same sensitivity list even
accross hierarchy.

If you wanted a little more privacy in a large single process, you
could use procedures with local variables to create islands of
locality within one process. You could still have "global" (within the
process) variables by declaring those before the procedures in the
process' declarative region.

To expand upon the timer/fsm example I posted a couple of weeks ago,
you could have a timer procedure and an fsm procedure within a
process, with local and "global" variables as desired. E.g. If the
timer/timeout variables were declared before both procedures, then
they could be read and manipulated by both, but if the state variable
was declared within the FSM process, only FSM could read/manipulate
the state.

I have seen some of your examples illustrate the use of procedures in
template processes, but I don't remember any specific to scope
control.

Andy

Article: 143869
Subject: Re: Simple state machine output question
From: Mike Treseler <mtreseler@gmail.com>
Date: Fri, 30 Oct 2009 12:11:59 -0700
Links: << >>  << T >>  << A >>
Andy wrote:

> To expand upon the timer/fsm example I posted a couple of weeks ago,
> you could have a timer procedure and an fsm procedure within a
> process, with local and "global" variables as desired. E.g. If the
> timer/timeout variables were declared before both procedures, then
> they could be read and manipulated by both, but if the state variable
> was declared within the FSM process, only FSM could read/manipulate
> the state.

I hear what you're saying.
If I had to put unrelated registers in the same entity,
I would do it like that.

I prefer to keep related registers together
and port map the wired interfaces to keep
the signal directions explicit.

> I have seen some of your examples illustrate the use of procedures in
> template processes, but I don't remember any specific to scope
> control.

I use port maps for scope control.

    -- Mike Treseler

Article: 143870
Subject: Re: save data from adc in text file
From: austin <austin@xilinx.com>
Date: Fri, 30 Oct 2009 14:30:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
Why not,

Just use Hyperterminal in the capture mode to record everything coming
in on the RS232 port from the uart?

Then use a text editor, perl script, or whatever to extract the
information you want (if it needs filtering).

I am presuming the text file resides on the same computer the RS232 is
connected to, so this just makes more sense that what you seem to be
doing.

Austin

Article: 143871
Subject: Re: Chipscope with Verilog
From: sandbender <pete@coho.org>
Date: Fri, 30 Oct 2009 15:06:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
Jon,

In the RTL there is not much you can do except add the signals to the
port list and bring them on up the hierarchy. Synthesis tools don't
support hierarchical references to nets. To do so they would have to
flatten the design hierarchy and it is not always wise to do that.

I usually just make a bus of all the signals in the child modules and
then route that up. If you use Xilinx's ChipScope insertion tool, then
this can do the work for you. The downside is that that tool is
terrible. In fact all the ChipScope tools are abysmal to use. I do
everything by hand and then only use the ChipScope analyzer tool. I
even name the signals by hand because the Xilinx tools are so bad. I
wish they would at least use a sane XML input format and document that
so we could just write scripts to feed the design information in. Even
better would be to publish the JTAG commands and let someone suck up
the information and stick it in a VCD file that could be read by your
favorite waveform viewer.

-Pete

On Oct 28, 6:36=A0am, "maxascent" <maxasc...@yahoo.co.uk> wrote:
> I have a design with some level of hierarchy and I want to connect a
> chipscope ILA core to the bottom level.
>
> For example say I have 3 modules A, B and C with a signal temp in C.
> Module A is the top level with B inside A and C inside B.
> I would of thought that I could just do the following
>
> chipscope_ila U_ila(
> =A0 =A0.CLK =A0 =A0 (clk),
> =A0 =A0.CONTROL (control),
> =A0 =A0.TRIG0 =A0 (A.B.C.temp));
>
> The ila is in the top level and I want to monitor temp.
> When I try and synthesize it with Synplify the program just errors.
> Can anyone tell me what I am ddoing wrong?
>
> Thanks
>
> Jon =A0 =A0 =A0 =A0
>
> --------------------------------------- =A0 =A0 =A0 =A0
> This message was sent using the comp.arch.fpga web interface onhttp://www=
.FPGARelated.com


Article: 143872
Subject: Re: Best way to model a large external ROM in a simulation? (XST simulator)
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Fri, 30 Oct 2009 23:14:44 +0000
Links: << >>  << T >>  << A >>
On Fri, 30 Oct 2009 06:50:28 -0700 (PDT), Andy <jonesandy@comcast.net> wrote:

>You can also initialize a constant, variable, or signal with a
>function call that returns the value to be used for initialization. So
>if you have a simple enough algorithm for the contents to code in
>vhdl, that might be a simpler way yet.

This is good, and any simulator will initialise the ROM fast. If it's junt for
the testbench this is a really good idea.

It is also synthesisable, and XST will handle it correctly ... 

BUT

(you just knew there was a BUT coming)

for a reasonably large ROM, or a complex function (e.g. function calls nested 4
levels deep) XST will take an unbelievably long time to synthesise it. There's
an N^2 algorithm in there somewhere; if it takes 15 minutes for a 1000 element
array, it'll take an hour for 2000 elements, 4 hours for 4000, etc...

This is an unbelievably weak area of XST's performance, and every simulator I've
tried proves this poor performance is completely unnecessary.

>If you can use an integer (range constraints withstanding), it will be
>smaller and more efficient. The VHDL LRM requires AT LEAST the range
>-2147483647 to 2147483647 to be implemented for integer, but many
>(most?) implementations handle the entire 32 bit two's complement
>range.

Modelsim handles -2^32, ISE Simulator gives a clear error message.

- Brian



Article: 143873
Subject: Re: Best way to model a large external ROM in a simulation? (XST simulator)
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 30 Oct 2009 23:24:44 +0000
Links: << >>  << T >>  << A >>
On Fri, 30 Oct 2009 23:14:44 +0000, Brian Drummond wrote:

>for a reasonably large ROM, or a complex function (e.g. function calls nested 4
>levels deep) XST will take an unbelievably long time to synthesise it. There's
>an N^2 algorithm in there somewhere; if it takes 15 minutes for a 1000 element
>array, it'll take an hour for 2000 elements, 4 hours for 4000, etc...

Sounds as though XST is re-invoking the entire function to 
compute the value of each individual bit (or word?) of the 
ROM.  Given the way synthesis tends to focus on each bit 
individually, that might be not too surprising.  Yuck.
-- 
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.

Article: 143874
Subject: Re: Chipscope with Verilog
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Fri, 30 Oct 2009 16:58:31 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Oct 30, 3:06=A0pm, sandbender <p...@coho.org> wrote:
> Jon,
>
> In the RTL there is not much you can do except add the signals to the
> port list and bring them on up the hierarchy. Synthesis tools don't
> support hierarchical references to nets. To do so they would have to
> flatten the design hierarchy and it is not always wise to do that.
>
> I usually just make a bus of all the signals in the child modules and
> then route that up. If you use Xilinx's ChipScope insertion tool, then
> this can do the work for you. The downside is that that tool is
> terrible. In fact all the ChipScope tools are abysmal to use. I do
> everything by hand and then only use the ChipScope analyzer tool. I
> even name the signals by hand because the Xilinx tools are so bad. I
> wish they would at least use a sane XML input format and document that
> so we could just write scripts to feed the design information in. Even
> better would be to publish the JTAG commands and let someone suck up
> the information and stick it in a VCD file that could be read by your
> favorite waveform viewer.
>
> -Pete
>
> On Oct 28, 6:36=A0am, "maxascent" <maxasc...@yahoo.co.uk> wrote:
>
>
>
> > I have a design with some level of hierarchy and I want to connect a
> > chipscope ILA core to the bottom level.
>
> > For example say I have 3 modules A, B and C with a signal temp in C.
> > Module A is the top level with B inside A and C inside B.
> > I would of thought that I could just do the following
>
> > chipscope_ila U_ila(
> > =A0 =A0.CLK =A0 =A0 (clk),
> > =A0 =A0.CONTROL (control),
> > =A0 =A0.TRIG0 =A0 (A.B.C.temp));
>
> > The ila is in the top level and I want to monitor temp.
> > When I try and synthesize it with Synplify the program just errors.
> > Can anyone tell me what I am ddoing wrong?
>
> > Thanks
>
> > Jon =A0 =A0 =A0 =A0
>
> > --------------------------------------- =A0 =A0 =A0 =A0
> > This message was sent using the comp.arch.fpga web interface onhttp://w=
ww.FPGARelated.com- Hide quoted text -
>
> - Show quoted text -

It is not necessary to insert the ICON and ILA cores in your original
HDL.  You can use the ChipScope Inserter to do this on your
synthesized design.

http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/chipscope_p=
ro_sw_cores_11_1_ug029.pdf

Ed McGettigan
--
Xilinx Inc.



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search