Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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
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 JenningsArticle: 144978
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? RickArticle: 144979
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.orgArticle: 144980
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.orgArticle: 144981
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 SulimmaArticle: 144982
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: 144983An 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.orgArticle: 144984
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.orgArticle: 144985
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.orgArticle: 144986
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
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: 144988Hello 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.comArticle: 144989
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.comArticle: 144990
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. RickArticle: 144991
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: 144992On 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. RickArticle: 144993
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, KE5FXArticle: 144994
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 BromleyArticle: 144995
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
"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 KellettArticle: 144997
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) - BrianArticle: 144998
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
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:
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