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 144975

Article: 144975
Subject: Re: Altera Quartus II on Debian GNU/Linux
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: Mon, 18 Jan 2010 15:06:51 +0100
Links: << >>  << T >>  << A >>
General Schvantzkoph <schvantzkoph@yahoo.com> writes:

> on Fedora but does work on 64 bit CentOS5. The Quartus 9.1 GUI is very 
> buggy, at least it is the way I run it which is to ssh into a CentOS5.4 
> VM. You have to be extremely delicate when you select a file to open from 
> Quartus, dragging the mouse over a file name will cause a modal box to 
> appear which hangs the interface about 50% of the time. The only solution 

I do all my builds using scripts, but sometimes I use the GUI to run
signaltap, the pin editor, chip planner, timing analyzer, megawizard,
and sopc builder. I've never experienced problems like you describe. I
don't get any modal boxes appearing whenever I move the mouse over
filenames in the open dialog box. I'm using Quartus 9.0 and 9.1 under
Gentoo with the sawfish window manager. I'm running most of my builds
on a remote machine over X11, but some builds are done locally
depending upon the load on the machines.

> I've found that I can't run SignalTap reliably from a native CentOS5.4 
> machine, the Linux driver for the download cable is crap. The Linux 

I've had minor problems with SignalTap under Linux in the past
(Quartus 7/8 or earlier if memory serves me right). But since 9.x I
haven't seen any problems and I use SignalTap, gdb, quartus_pgm, and
nios2-download, both locally and remotely using the Altera JTAG
server. However, I tend to instantiate megawizard generated signaltap
components rather than building them in the GUI.

> driver for Chipscope is also a pain, it would be nice if Altera and 
> Xilinx would provide proper GPLed drivers for their download cable so 

Or at least document the API, so I could make a signaltap and
chipscope interface for my ethernet based programmer.


Petter
-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Article: 144976
Subject: Re: Altera Quartus II on Debian GNU/Linux
From: General Schvantzkoph <schvantzkoph@yahoo.com>
Date: 18 Jan 2010 14:38:36 GMT
Links: << >>  << T >>  << A >>
On Mon, 18 Jan 2010 15:06:51 +0100, Petter Gustad wrote:

> General Schvantzkoph <schvantzkoph@yahoo.com> writes:
> 
>> on Fedora but does work on 64 bit CentOS5. The Quartus 9.1 GUI is very
>> buggy, at least it is the way I run it which is to ssh into a CentOS5.4
>> VM. You have to be extremely delicate when you select a file to open
>> from Quartus, dragging the mouse over a file name will cause a modal
>> box to appear which hangs the interface about 50% of the time. The only
>> solution
> 
> I do all my builds using scripts, but sometimes I use the GUI to run
> signaltap, the pin editor, chip planner, timing analyzer, megawizard,
> and sopc builder. I've never experienced problems like you describe. I
> don't get any modal boxes appearing whenever I move the mouse over
> filenames in the open dialog box. I'm using Quartus 9.0 and 9.1 under
> Gentoo with the sawfish window manager. I'm running most of my builds on
> a remote machine over X11, but some builds are done locally depending
> upon the load on the machines.

My set up is as follows. My workstation and my servers are all running 64 
bit Fedora 12, the workstation is running Gnome the servers run at Init 
3. I'm running Quartus 9.1 on a KVM 64 bit CentOS5.4. VM (Init 3) on my 
servers. I ssh into the VM and then execute Quartus from an Xemacs shell. 
Quartus is the only program that gives me any trouble.

Article: 144977
Subject: Re: Simulation of VHDL code for a vending machine
From: KJ <kkjennings@sbcglobal.net>
Date: Mon, 18 Jan 2010 06:45:14 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 18, 8:49=A0am, Gabor <ga...@alacron.com> wrote:
> On Jan 17, 7:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > > In the end,
> > > it more a matter of preference than anything. =A0If you like the form=
at
> > > of your code using Booleans, go ahead. =A0There are no real roadblock=
s
> > > 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. =A0"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

Article: 144978
Subject: Re: Simulation of VHDL code for a vending machine
From: rickman <gnuarm@gmail.com>
Date: Mon, 18 Jan 2010 07:25:24 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 18, 8:49=A0am, Gabor <ga...@alacron.com> wrote:
> On Jan 17, 7:49=A0pm, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > > In the end,
> > > it more a matter of preference than anything. =A0If you like the form=
at
> > > of your code using Booleans, go ahead. =A0There are no real roadblock=
s
> > > 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. =A0"Uninitialized"
> logic in an FPGA generally defaults to zero, at least for
> Xilinx XST. =A0There 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.

This is an interesting issue.  I deal with this by always initializing
registers which should be good enough to control a simulation and
should match what happened inside the FPGA.

As to Booleans, do they ever get implemented as False =3D High?  Some
parts I have worked with do not have inverters in some spots which
then require that the signal sense be flipped to eliminate a LUT used
as an inverter.  I would think the hardware default of the Boolean
would then not be a False.  Oh, maybe this is moot.  On further
reflection, the case where the signal is inverted is when the initial
state of the FF is High and the part has no set capability!  So that
wouldn't be an issue in this case.  But are there other times when a
Boolean would be inverted?

Rick

Article: 144979
Subject: Re: Altera Quartus II on Debian GNU/Linux
From: whygee <yg@yg.yg>
Date: Mon, 18 Jan 2010 17:11:41 +0100
Links: << >>  << T >>  << A >>
David Brown wrote:
> I don't remember the details, but I believe that both Altera and Xilinx 
> used the same windows-to-linux library originally for their Linux ports, 
> and that that particular library was royalty based.  Being royalty 
> based, it is very difficult to make it available freely.
that is coherent with what I have heard from rep/sales people in tradeshows...

> I guess they 
> had good reason for picking that library at the time, but it has always 
> seemed strange to me that the software should be build so strongly on 
> *nix style solutions (lots of perl and tcl, amongst other things) and 
> yet be so difficult to move to Linux.
who knows why :-/

yg
-- 
http://ygdes.com / http://yasep.org

Article: 144980
Subject: bit vs std_logic (was Re: Simulation of VHDL code for a vending machine)
From: whygee <yg@yg.yg>
Date: Mon, 18 Jan 2010 17:36:07 +0100
Links: << >>  << T >>  << A >>
Hi,

Gabor wrote:
> On Jan 17, 7:49 pm, KJ <kkjenni...@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.

But if we assume that the registers are correctly initialised
by a correct Reset signal, and the design is verified with std_logic,
a higher-level simulation (that deals more with using already
tested sub-functions), then we could swap the std_logic
with "bit"-based types to increase simulation speed ?

I'm diving into GHDL which is not as fast as, say... ncsim,
but has much more potential for me, so simulation time matters.
Not much yet but if I can cut the simulation time by one half,
simply by defining my signals differently, I take it :-)
I'm considering writing a couple of similar VHDL packages
that define local types for the wires, one that uses bits
and the other std_logic : I'm curious to see the simulation
speed difference.

Note that, with a nice simple testbench with clean signals and edges,
dirty setup conditions with /RESET don't usually happen,
so I don't expect Us or Xs to propagate through the whole design ;-)

Has anyone already explored this path ?

> Regards,
_o/
> Gabor
yg

-- 
http://ygdes.com / http://yasep.org

Article: 144981
Subject: Re: bit vs std_logic (was Re: Simulation of VHDL code for a vending
From: Kolja Sulimma <ksulimma@googlemail.com>
Date: Mon, 18 Jan 2010 10:25:20 -0800 (PST)
Links: << >>  << T >>  << A >>
On 18 Jan., 17:36, whygee <y...@yg.yg> wrote:

> I'm diving into GHDL which is not as fast as, say... ncsim,
> but has much more potential for me, so simulation time matters.
> Not much yet but if I can cut the simulation time by one half,
> simply by defining my signals differently, I take it :-)
> I'm considering writing a couple of similar VHDL packages
> that define local types for the wires, one that uses bits
> and the other std_logic : I'm curious to see the simulation
> speed difference.

Note that a lot of the simulation time is take up by resolution
functions.
STD_ULOGIC should be a lot faster than STD_LOGIC.
As there are no tristates in FPGAs anyway nowadays there is hardly
any reason to use STD_LOGIC at all.

Kolja Sulimma

Article: 144982
Subject: Re: bit vs std_logic (was Re: Simulation of VHDL code for a vending machine)
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Mon, 18 Jan 2010 19:36:45 +0100
Links: << >>  << T >>  << A >>
On Mon, 18 Jan 2010 17:36:07 +0100, whygee wrote:

>Note that, with a nice simple testbench with clean signals and edges,
>dirty setup conditions with /RESET don't usually happen,
>so I don't expect Us or Xs to propagate through the whole design ;-)
>
>Has anyone already explored this path ?

I haven't, but it has been thoroughly explored in the
verification literature.  That's one of the reasons why
SystemVerilog added 2-state variables (int, bit) to the
language; VHDL has had 2-state integer, bit and boolean
from the outset, of course.

There is some strong evidence to suggest that X-simulation
is not only inconvenient because spurious Xs tend to
chase around the design when in reality it's OK, but also
they can give rise to unjustified optimism because of
the way certain RTL control constructs handle X inputs.
For example, in Verilog...

  if (mode2)
    do_mode2_stuff;
  else
    do_mode1_stuff;

If (mode2) is 1'bx in RTL simulation, the if() statement 
will take its else-branch and the simulation will act
exactly as if (mode2) was zero.

So an alternative, which has been reported as giving
good results, is to use 2-state simulation **but to 
randomize the values of all register variables at 
startup**.  If you use different seeds for the 
randomization, you can simulate the design with a
wide range of startup values and therefore can see
whether it will reliably come out of reset.  This 
works nicely for ASIC designs where flip-flops
may power-up in an unknown state but the design
is nevertheless well-behaved.  Consider, for example,
a simple clock divide-by-2 that has no reset - it 
shoudl be OK in practice, but will be stuck at X
in a 4-state traditional simulation.

I believe that some simulators offer this startup
randomization as an option.

For a nice discussion of the drawbacks of 4-state
simulation, see Mike Turpin's survey at
  http://www.arm.com/pdfs/Verilog_X_Bugs.pdf
The paper discusses Verilog, but many of the same
ideas map on to VHDL (although a lot of the details
are different).
-- 
Jonathan Bromley

Article: 144983
Subject: Re: bit vs std_logic (was Re: Simulation of VHDL code for a vending
From: whygee <yg@yg.yg>
Date: Mon, 18 Jan 2010 19:39:21 +0100
Links: << >>  << T >>  << A >>
An interesting thread is probably coming,
should we Xpost to comp.lang.vhdl ?

Kolja Sulimma wrote:
> Note that a lot of the simulation time is take up by resolution functions.
> STD_ULOGIC should be a lot faster than STD_LOGIC.
> As there are no tristates in FPGAs anyway nowadays there is hardly
> any reason to use STD_LOGIC at all.

That's what I thought. But recently (this summer)
I have been told to use STD_LOGIC anyway,
I don't remember why. There is hardly any
modification to my existing code because
I don't rely on resolution functions
or multiple-driver behaviour.
It was a pain (as anything VHDL-related)
to change all the declarations and interfaces
(both in the designs and the testbenches)
but it simply worked.

But this was only for synthesis.
I am wondering now what to do for high-level
simulations, when all the std_logic-ness
does not play any role anymore.
And with GHDL, for which integer directly maps
to the same C idiom, there are certainly
a lot of things to win (space, time)...

> Kolja Sulimma
yg

-- 
http://ygdes.com / http://yasep.org

Article: 144984
Subject: Re: bit vs std_logic (was Re: Simulation of VHDL code for a vending
From: whygee <yg@yg.yg>
Date: Mon, 18 Jan 2010 20:35:08 +0100
Links: << >>  << T >>  << A >>
Jonathan Bromley wrote:
> On Mon, 18 Jan 2010 17:36:07 +0100, whygee wrote:
>> Has anyone already explored this path ?
> 
> I haven't, but it has been thoroughly explored in the
> verification literature.
Can you point me to any online paper or website about this subject ?

>  That's one of the reasons why
> SystemVerilog added 2-state variables (int, bit) to the
> language; VHDL has had 2-state integer, bit and boolean
> from the outset, of course.
yes, the ADA legacy has some good advantages :-)

> There is some strong evidence to suggest that X-simulation
> is not only inconvenient because spurious Xs tend to
> chase around the design when in reality it's OK,
I've seen this too, the false positives are quite annoying :-/

> but also
> they can give rise to unjustified optimism because of
> the way certain RTL control constructs handle X inputs.
> For example, in Verilog...
> 
>   if (mode2)
>     do_mode2_stuff;
>   else
>     do_mode1_stuff;
> 
> If (mode2) is 1'bx in RTL simulation, the if() statement 
> will take its else-branch and the simulation will act
> exactly as if (mode2) was zero.
heh, good point !

> So an alternative, which has been reported as giving
> good results, is to use 2-state simulation **but to 
> randomize the values of all register variables at 
> startup**.  If you use different seeds for the 
> randomization, you can simulate the design with a
> wide range of startup values and therefore can see
> whether it will reliably come out of reset.  This 
> works nicely for ASIC designs where flip-flops
> may power-up in an unknown state but the design
> is nevertheless well-behaved.  Consider, for example,
> a simple clock divide-by-2 that has no reset - it 
> shoudl be OK in practice, but will be stuck at X
> in a 4-state traditional simulation.
> 
> I believe that some simulators offer this startup
> randomization as an option.
I've explored this around 2001 :-)
and I have then run into file read issues
from VHDL and compatibility issues with
different simulators. But it worked quite
well on a few platforms.


> For a nice discussion of the drawbacks of 4-state
> simulation, see Mike Turpin's survey at
>   http://www.arm.com/pdfs/Verilog_X_Bugs.pdf
> The paper discusses Verilog, but many of the same
> ideas map on to VHDL (although a lot of the details
> are different).
i'll check that, thanks !

yg
-- 
http://ygdes.com / http://yasep.org

Article: 144985
Subject: Re: bit vs std_logic (was Re: Simulation of VHDL code for a vending
From: whygee <yg@yg.yg>
Date: Mon, 18 Jan 2010 20:51:12 +0100
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> whygee wrote:
>> But recently (this summer)
>> I have been told to use STD_LOGIC anyway,
>> I don't remember why.
> 
> That is the common default for bits.
?

> The *only* advantage is it covers tristate signals.
sure. But I don't have/need tristates.

> Otherwise std_ulogic can detect multiple drivers
> at compile time and has no downside
> as it is 100% compatible with std_logic.
I still don't remember how/why I was convinced to drop ulogic
but I switched anyway.
It was probably something about externally provided
(or proprietary/manufacturer-specific) code interface...

> Vectors are a more complicated story.
I don't see what could go wrong...

well, except this whole mess with
integer/signed/unsigned/bit_vector/std_logic_vector/std_ulogic_vector
translations/type casts :-/

>      -- Mike Treseler
yg

-- 
http://ygdes.com / http://yasep.org

Article: 144986
Subject: Re: bit vs std_logic (was Re: Simulation of VHDL code for a vending
From: Mike Treseler <mtreseler@gmail.com>
Date: Mon, 18 Jan 2010 11:56:05 -0800
Links: << >>  << T >>  << A >>
whygee wrote:

> Kolja Sulimma wrote:
>> Note that a lot of the simulation time is take up by resolution 
>> functions.
>> STD_ULOGIC should be a lot faster than STD_LOGIC.
>> As there are no tristates in FPGAs anyway nowadays there is hardly
>> any reason to use STD_LOGIC at all.
> 
> That's what I thought. But recently (this summer)
> I have been told to use STD_LOGIC anyway,
> I don't remember why.

That is the common default for bits.
The *only* advantage is it covers tristate signals.
Otherwise std_ulogic can detect multiple drivers
at compile time and has no downside
as it is 100% compatible with std_logic.
Vectors are a more complicated story.

      -- Mike Treseler

Article: 144987
Subject: Using a timer in EDK 11.
From: Griffin <captain.griffin@gmail.com>
Date: Mon, 18 Jan 2010 13:40:17 -0800 (PST)
Links: << >>  << T >>  << A >>
Hello,

I'm trying to implement code that reads in some software registers
from a peripheral after constant time intervals (ideally, a
microsecond or so). I know that EDK comes with a hardware timer
(xps_timer) and what I think is a software timer (fit_timer) and I
know how to add them to my project as well as attach them to the PLB,
but I haven't been able to find any documentation (xapp, etc.) as to
how to use either to actually time some events.

In a nutshell, I need my code to execute as follows:

while(some condition) do {
-read in software register (their values change with time)
-store the value to ddr to be used later
-wait 1 microsecond (or any arbitrary time).
}


I need to make sure that the time intervals between every time the
software register is read in are the same, always, *and* I need to
know how long that interval is, which is why I can't use a simple
while loop. From what I've seen on the Internet, using one of these
two timers seems to be the way to go.

Any advice / suggestions / examples would be greatly appreciated.

I'm using EDK 11.2 .

Thanks in advance.

-Sean.


Article: 144988
Subject: working with ADC and DAC together
From: "mlajevar" <mahsa_lajevardi@n_o_s_p_a_m.yahoo.com>
Date: Mon, 18 Jan 2010 16:33:12 -0600
Links: << >>  << T >>  << A >>
Hello

I have the vhdl code for both amplifier-ADC and DAC of spartan3E,now I want
to combine them together.Actually the purpose is to get an analog avlue
from oscilloscope send it to FPGA(through my vhdl code for ADC ,it is
converted to digital,and via the code for DAC, it will be converted to
analog voltage)and check the analog output to see if it is similar ti the
analog input we applied to ADC  at first.

I am going to consider two different states for DAC and ADC, and just to
turn around these two states.I know that SPI bus will be shared between
them ,so I konw I have to disable DAC ,while working with ADC and vice
versa.

my question is how much I have to wait(in MHz) to go from ADC state to DAC
and vice versa.

I appreciate alot if you let me know about your ideas.

thanks in advance	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Article: 144989
Subject: compiler output to fpga.
From: "akshayvreddy" <akshayvreddy@gmail.com>
Date: Mon, 18 Jan 2010 18:07:01 -0600
Links: << >>  << T >>  << A >>
Hello, 
I am implementing a processor design on the virtex 2 chip. The Design was
done using verilog with Xilinx 10.1 and modelsim. I have a compiler of the
design. 

My question is:is there a way to integrate the compiler output with the
FPGA using modelsim simulator without actually programming the fpga. I am
using a windows system and the complier is C based.

Thank you
Akshay

	   
					
---------------------------------------		
This message was sent using the comp.arch.fpga web interface on
http://www.FPGARelated.com

Article: 144990
Subject: Re: bit vs std_logic (was Re: Simulation of VHDL code for a vending
From: rickman <gnuarm@gmail.com>
Date: Mon, 18 Jan 2010 17:25:04 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 18, 2:51=A0pm, whygee <y...@yg.yg> wrote:
> Mike Treseler wrote:
> > whygee wrote:
> >> But recently (this summer)
> >> I have been told to use STD_LOGIC anyway,
> >> I don't remember why.
>
> > That is the common default for bits.
>
> ?
>
> > The *only* advantage is it covers tristate signals.
>
> sure. But I don't have/need tristates.
>
> > Otherwise std_ulogic can detect multiple drivers
> > at compile time and has no downside
> > as it is 100% compatible with std_logic.
>
> I still don't remember how/why I was convinced to drop ulogic
> but I switched anyway.
> It was probably something about externally provided
> (or proprietary/manufacturer-specific) code interface...
>
> > Vectors are a more complicated story.
>
> I don't see what could go wrong...
>
> well, except this whole mess with
> integer/signed/unsigned/bit_vector/std_logic_vector/std_ulogic_vector
> translations/type casts :-/
>
> > =A0 =A0 =A0-- Mike Treseler
>
> yg
>
> --http://ygdes.com/http://yasep.org

After struggling with VHDL type casting for some time, I finally
settled on using signed/unsigned for the majority of the vectors I
use.  I seldom use integers other than perhaps memory where it
simulates much faster with a lot less memory.  But nothing is
absolute.  I just try to be consistent within a given design.  I have
never used bit types, but the discussion here about the advantages of
ulogic over logic is interesting.  I certainly like to speed up my
simulations.  But it is such a PITA to get away from std_logic.  I
don't recall if ieee.numeric_std converts between ulogic and the
signed/unsigned types.  It is so verbose to use multiple conversions
in one assignment.

Rick

Article: 144991
Subject: XST is driving me mad.
From: ghelbig <ghelbig@lycos.com>
Date: Mon, 18 Jan 2010 18:28:21 -0800 (PST)
Links: << >>  << T >>  << A >>
I've been trying to make a _simple_ counter work, and it just doesn't.

Can I get another set of eyes to look at this?  It's probably
something dumb/simple, but I just can't see it.

The code:

reg [3:0] DCM_Delay = 4'hF;
reg DCM_Reset = 1'b1;

   always @ (posedge clk_fpga) begin
      if (reset) begin
         DCM_Reset <= 1'b1;
         DCM_Delay <= 4'hF;
      end else begin
         if (|DCM_Delay) begin
            DCM_Reset <= 1'b1;
            DCM_Delay <= DCM_Delay - 1;
         end else begin
            DCM_Reset <= 1'b0;
         end
      end
   end


Comments:

"reset" is the inversion of a push-button.  I can bring it to a pin,
and see that it is OK.

I can put the DCM_Delay bus on pins - it's always high.

I never see the counter count.  What am I missing?  I tried
initialising DCM_Delay to all 0's to see if reset did anything - it
seems to be ignored.

I added 'reset' to the sensitivity list - that didn't help.

What am I missing?

Argh,
Gary.

Article: 144992
Subject: Re: XST is driving me mad.
From: rickman <gnuarm@gmail.com>
Date: Mon, 18 Jan 2010 23:03:32 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 18, 9:28=A0pm, ghelbig <ghel...@lycos.com> wrote:
> I've been trying to make a _simple_ counter work, and it just doesn't.
>
> Can I get another set of eyes to look at this? =A0It's probably
> something dumb/simple, but I just can't see it.
>
> The code:
>
> reg [3:0] DCM_Delay =3D 4'hF;
> reg DCM_Reset =3D 1'b1;
>
> =A0 =A0always @ (posedge clk_fpga) begin
> =A0 =A0 =A0 if (reset) begin
> =A0 =A0 =A0 =A0 =A0DCM_Reset <=3D 1'b1;
> =A0 =A0 =A0 =A0 =A0DCM_Delay <=3D 4'hF;
> =A0 =A0 =A0 end else begin
> =A0 =A0 =A0 =A0 =A0if (|DCM_Delay) begin
> =A0 =A0 =A0 =A0 =A0 =A0 DCM_Reset <=3D 1'b1;
> =A0 =A0 =A0 =A0 =A0 =A0 DCM_Delay <=3D DCM_Delay - 1;
> =A0 =A0 =A0 =A0 =A0end else begin
> =A0 =A0 =A0 =A0 =A0 =A0 DCM_Reset <=3D 1'b0;
> =A0 =A0 =A0 =A0 =A0end
> =A0 =A0 =A0 end
> =A0 =A0end
>
> Comments:
>
> "reset" is the inversion of a push-button. =A0I can bring it to a pin,
> and see that it is OK.
>
> I can put the DCM_Delay bus on pins - it's always high.
>
> I never see the counter count. =A0What am I missing? =A0I tried
> initialising DCM_Delay to all 0's to see if reset did anything - it
> seems to be ignored.
>
> I added 'reset' to the sensitivity list - that didn't help.
>
> What am I missing?
>
> Argh,
> Gary.

Have you tried simulating this code?  It sounds like you are trying to
debug a chip.  Isn't it easier to use a simulator where you can see
every signal?  I am not as familiar with Verilog, but you might try
evaluating |DCM_Delay as a separate signal which can be viewed
independently.  I sometimes find brain cramps by being very deliberate
and looking for problems where I "know" they don't exist.

Rick

Article: 144993
Subject: Re: XST is driving me mad.
From: "jmiles@pop.net" <jmiles@gmail.com>
Date: Mon, 18 Jan 2010 23:50:01 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 18, 6:28=A0pm, ghelbig <ghel...@lycos.com> wrote:
> I've been trying to make a _simple_ counter work, and it just doesn't.
>
> Can I get another set of eyes to look at this? =A0It's probably
> something dumb/simple, but I just can't see it.
>
> The code:
>
> reg [3:0] DCM_Delay =3D 4'hF;
> reg DCM_Reset =3D 1'b1;
>
> =A0 =A0always @ (posedge clk_fpga) begin
> =A0 =A0 =A0 if (reset) begin
> =A0 =A0 =A0 =A0 =A0DCM_Reset <=3D 1'b1;
> =A0 =A0 =A0 =A0 =A0DCM_Delay <=3D 4'hF;
> =A0 =A0 =A0 end else begin
> =A0 =A0 =A0 =A0 =A0if (|DCM_Delay) begin
> =A0 =A0 =A0 =A0 =A0 =A0 DCM_Reset <=3D 1'b1;
> =A0 =A0 =A0 =A0 =A0 =A0 DCM_Delay <=3D DCM_Delay - 1;
> =A0 =A0 =A0 =A0 =A0end else begin
> =A0 =A0 =A0 =A0 =A0 =A0 DCM_Reset <=3D 1'b0;
> =A0 =A0 =A0 =A0 =A0end
> =A0 =A0 =A0 end
> =A0 =A0end
>
> Comments:
>
> "reset" is the inversion of a push-button. =A0I can bring it to a pin,
> and see that it is OK.
>
> I can put the DCM_Delay bus on pins - it's always high.
>
> I never see the counter count. =A0What am I missing? =A0I tried
> initialising DCM_Delay to all 0's to see if reset did anything - it
> seems to be ignored.
>
> I added 'reset' to the sensitivity list - that didn't help.
>
> What am I missing?
>
> Argh,
> Gary.

What character is in front of DCM_Delay in that if statement?

-- john, KE5FX

Article: 144994
Subject: Re: XST is driving me mad.
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Tue, 19 Jan 2010 09:20:18 +0100
Links: << >>  << T >>  << A >>
On Mon, 18 Jan 2010 23:50:01 -0800 (PST), "jmiles@pop.net" wrote:

>>          if (|DCM_Delay) begin

>What character is in front of DCM_Delay in that if statement?

I hope it's a vertical bar, the reduction-OR operator;
that would make the test effectively "if (DCM_Delay != 0)"
(which would have been more readable anyway).

The code looks OK to me.  The counter DCM_Delay should
reset to 4'hf, count down to zero and then remain stuck at
zero until the next reset.  DCM_Reset should go to zero 
one clock after DCM_Delay reaches zero.

Is there any chance that (a) the clock is not ticking, or
(b) reset is stuck high?
-- 
Jonathan Bromley

Article: 144995
Subject: Easy PC software tool - Bad experience
From: "Roger" <rogerwilson@hotmail.com>
Date: Tue, 19 Jan 2010 11:29:56 -0000
Links: << >>  << T >>  << A >>
Due to a bug in the Easy PC software tool from Numberone Systems, I've just 
had a very time consuming and costly incident. Despite their faulty software 
costing me a lot of money, the company have so far taken the "hard luck" 
approach.

Has anyone else had any experience of Easy PC?

TIA,

Rog. 


Article: 144996
Subject: Re: Easy PC software tool - Bad experience
From: "MK" <mk@nospam.please>
Date: Tue, 19 Jan 2010 11:45:35 -0000
Links: << >>  << T >>  << A >>

"Roger" <rogerwilson@hotmail.com> wrote in message 
news:7LGdnRZPy6owCsjWnZ2dnUVZ8r-dnZ2d@brightview.co.uk...
> Due to a bug in the Easy PC software tool from Numberone Systems, I've 
> just had a very time consuming and costly incident. Despite their faulty 
> software costing me a lot of money, the company have so far taken the 
> "hard luck" approach.
>
> Has anyone else had any experience of Easy PC?
>
> TIA,
>
> Rog.

I've been using EasyPC for some years now - never had any problems at all. 
What was your problem (and what version were you using) - if there is a hole 
you can describe I might be able to avoid it !!

Michael Kellett 



Article: 144997
Subject: Re: compiler output to fpga.
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Tue, 19 Jan 2010 12:10:58 +0000
Links: << >>  << T >>  << A >>
On Mon, 18 Jan 2010 18:07:01 -0600, "akshayvreddy" <akshayvreddy@gmail.com>
wrote:

>Hello, 
>I am implementing a processor design on the virtex 2 chip. The Design was
>done using verilog with Xilinx 10.1 and modelsim. I have a compiler of the
>design. 
>
>My question is:is there a way to integrate the compiler output with the
>FPGA using modelsim simulator without actually programming the fpga. I am
>using a windows system and the complier is C based.
>
>Thank you
>Akshay

Yes.

Where is the program memory for the processor?

If external memory, you can modify a memory model to load (and save) its
contents from a file. I have done this by adding extra "load", "save" and
"filename" ports to a memory model I originally downloaded from a memory
manufacturer (Cypress), and driving them from the testbench.

Actually loading an object code file is then a simple matter of programming.

If you are using BRAMs, you can instantiate them and translate your object code
into their INIT_nn generics. 

But it is much better and easier to infer a ROM as a constant array, initialised
by a function (which is called during elaboration). That function could read
your object file into the ROM. Or you could write another program to translate
the object format into a VHDL package containing your constant array.

(I don't know Verilog but I expect it can do these things too)

- Brian

Article: 144998
Subject: Re: XST is driving me mad.
From: Gabor <gabor@alacron.com>
Date: Tue, 19 Jan 2010 06:01:48 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 19, 3:20=A0am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Mon, 18 Jan 2010 23:50:01 -0800 (PST), "jmi...@pop.net" wrote:
> >> =A0 =A0 =A0 =A0 =A0if (|DCM_Delay) begin
> >What character is in front of DCM_Delay in that if statement?
>
> I hope it's a vertical bar, the reduction-OR operator;
> that would make the test effectively "if (DCM_Delay !=3D 0)"
> (which would have been more readable anyway).
>
> The code looks OK to me. =A0The counter DCM_Delay should
> reset to 4'hf, count down to zero and then remain stuck at
> zero until the next reset. =A0DCM_Reset should go to zero
> one clock after DCM_Delay reaches zero.
>
> Is there any chance that (a) the clock is not ticking, or
> (b) reset is stuck high?
> --
> Jonathan Bromley
or
(c) the lights are inverted and DCM_Delay bits are really all zero?

Article: 144999
Subject: Re: XST is driving me mad.
From: johnp <jprovidenza@yahoo.com>
Date: Tue, 19 Jan 2010 06:02:23 -0800 (PST)
Links: << >>  << T >>  << A >>
I assume you're using the raw input clock for this reset logic?  If
you're
using the DCM output clock, it will nver count since the DCM is reset.


John Providenza



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