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
Hi, I have met some situations that people evaluate a design's complex degree by asking "How many states does the state machine have". I think any designs based on state machine can be rewritten to counter style, which does not have any state. And in many times a combined mode is used, which means only using a few states and each state has a counter inside. By using state machine, syn_encoding value can be adjusted dynamically. For example, when we cannot get the desired speed, we can set syn_encoding to onehot. But when the speed is ok, is the counter style enough? ThanksArticle: 113851
hi all, im in the process of designing and implementing a digital system on a spartan 3 FPGA. apart from the FPGA, im using two static RAM's and a CMOS image sensor for this design. Compared with other digital systems, this design is fairly simple. But im facing lot of trouble when it comes to debugging . Currently im using Chipscope pro for debugging, but the hassle of updating the connections and lack of block RAM for signal storage has forced me to investigate other possibilities for debugging. Since the design involves a CMOS sensor and a RAM, i cant do a full system simulation either. 1) Does any one know a better way of debugging? 2) Is it common to write a simulation model for external components(like CMOS sensor) so that the whole system can be simulated? im guessing at least one of the above should exist, as making a real world complex digital system with the methods im using currently will be very time consuming and error prone. any help is appreciated. thank you.Article: 113852
Yes it is common, and ofttimes very necessary, to simulate (HDL) external components. If you ever get into the ASIC world, or a large design within an FPGA, you will gain an appreciatiation for HDL-simulation. Large FPGA designs can take hours to compile (synthezize, place, and route) which makes gate level simulation a very ineffcient way to do digital design. Can you imagine a 2hr compile each time you made a change?! You could blow a whole day with just 4 changes!! Somtimes you can get third party vendors to supply you with an HDL model of their part, which then will allow you to simulate their component with your design. Our company has done this in the past with transceiver chips. Simulation is a learned art: meaning the more you do the better you get at it. Knowing how to stimulate your design and test the boundaries can be a challenging exercise, but one that can save your much work later on. If you skimp on simulating you'll usually pay for it later with debugging. But, if you're in the debugging phase, having a board connection (like a Mictor) to a digital analyzer is always helpful. The downside is that it takes pins to bring out the signals, but at least you're not limited by block RAM and the hassle of updating connections. One could even provide a programmable test port which would allow you to dynamically pick which signals come out of the debug port w/o having to re-compile your design. Debugging can be extremely frustrating--I know because I've been there. But you can look forward to doing the Engineer Victory Dance (taken from Dilbert) when you find the problem :) "CMOS" <manusha@millenniumit.com> wrote in message news:1167056485.058185.73520@a3g2000cwd.googlegroups.com... > hi all, > > im in the process of designing and implementing a digital system on a > spartan 3 FPGA. apart from the FPGA, im using two static RAM's and a > CMOS image sensor for this design. Compared with other digital systems, > this design is fairly simple. But im facing lot of trouble when it > comes > to debugging . Currently im using Chipscope pro for debugging, but the > hassle of updating the connections and lack of block RAM for signal > storage has forced me to investigate other possibilities for debugging. > Since the design involves a CMOS sensor and a RAM, i cant do a full > system simulation either. > > 1) Does any one know a better way of debugging? > 2) Is it common to write a simulation model for external > components(like CMOS sensor) so that the whole system can be simulated? > > > im guessing at least one of the above should exist, as making a real > world complex digital system with the methods im using currently will > be very time consuming and error prone. > > any help is appreciated. > > thank you. >Article: 113853
We got most of recent designs done in the former xlinx version 8.1 and consider continuing with the most recent version 8.2. Since it seems not be possible to reasily step back, once having converted to 8.2, I'd like to ask for experiences with the newer version. At the point of time, some difficulties with project behaviour and stability have been reported to me from others and I wonder if it is more risky to stay with the old version or better go for the new one. (?) Another information says, that Xlilinx will come out with a new version 9.0 in the near future. Anything about that ? Hints are welcome. ThanksArticle: 113854
"fpgauser" <fpgaengineerfrankfurt@arcor.de> schrieb im Newsbeitrag news:1167073964.360111.239060@a3g2000cwd.googlegroups.com... > We got most of recent designs done in the former xlinx version 8.1 and > consider continuing with the most recent version 8.2. Since it seems > not be possible to reasily step back, once having converted to 8.2, I'd > like to ask for experiences with the newer version. > > At the point of time, some difficulties with project behaviour and > stability have been reported to me from others and I wonder if it is > more risky to stay with the old version or better go for the new one. > (?) > > Another information says, that Xlilinx will come out with a new version > 9.0 in the near future. Anything about that ? > > Hints are welcome. Thanks > Xilinx has announced Virtex-5 and Spartan-3A but there is no full support for them in 8.2 (Data2mem does not support them) so I would say Xilinx has to come out with 9.1 very soon. I think it is(or was) targeted for release in January Antti BTW webcase solutions already give responses like "this bug will be fixed in 9.1 SP1" so 9.1 should be actually ready for release if the new bugs are already scheduled for 9.1 SP1 and not 9.1 main releaseArticle: 113855
On 24 Dec 2006 04:16:54 -0800, "Venu" <get2venu@gmail.com> wrote: >Hi, > >I am designing an OPB Peripheral which has to act as a master and a >slave on the OPB Bus . I am not happy with the IPIF master logic >functionality provided by Xilinx . I am trying to design the master >logic support myself , but the VHDL code for the Xilinx implementation >is not provided in any of the directories .. Does any one have any >documents / app notes , which discusses guidelines for the master logic >design? > Just read the OPB specification (take a look at OPB bus pdf inside SDK), it is really easy to write an OPB bus master Bets regards, Zara BTW: Do it more parametrized, so you may reuse it.Article: 113856
set XIL_IMPACT_ENV_LPT_BASE_ADDRESS=D880 set XIL_IMPACT_ENV_LPT_ECP_ADDRESS=D800 like this, works! until that I was very upset that impact was not able to talk to my pci superio card AnttiArticle: 113857
On 25 Dec 2006 11:12:44 -0800, "fpgauser" <fpgaengineerfrankfurt@arcor.de> wrote: <snip> One reason *I* need to use 8.2 rather than 8.1- to quote from "What's New": ## iMPACT Support for direct programming of SPI FLASH PROMs from AtmelŽ and ST MicroŽ. ## -this explained the frustration of my being unable to use a Spartan3E board from Avnet, while a colleague with v8.2 used it OK. -- Per ardua ad nauseamArticle: 113858
"CMOS" <manusha@millenniumit.com> wrote: >hi all, > >im in the process of designing and implementing a digital system on a >spartan 3 FPGA. apart from the FPGA, im using two static RAM's and a >CMOS image sensor for this design. Compared with other digital systems, >this design is fairly simple. But im facing lot of trouble when it >comes >to debugging . Currently im using Chipscope pro for debugging, but the >hassle of updating the connections and lack of block RAM for signal >storage has forced me to investigate other possibilities for debugging. >Since the design involves a CMOS sensor and a RAM, i cant do a full >system simulation either. > >1) Does any one know a better way of debugging? I've been using the following method for years: I create a debug 'bus' inside the FPGA. I use a mux or tri-state buffers which can put internal signals onto 8 or 16 output pins. This allows me to monitor some essential signals from different modules and track down where something goes wrong using a logic analyzer. Because the debug bus grows together with the design, I can always monitor any module connected to the debug bus in the fpga without need for re-compiling. If a microcontroller is connected to an FPGA I make sure the microcontroller can write/read data into memories or filters for test purposes. During development, the microcontroller is very handy for generating test patterns and verifying results. >2) Is it common to write a simulation model for external >components(like CMOS sensor) so that the whole system can be simulated? I believe this is done very often but an error in the model will introduce an error in your design. You'll still need to verify the real-life timing on the external components with an oscilloscope or logic analyzer. -- Reply to nico@nctdevpuntnl (punt=.) Bedrijven en winkels vindt U op www.adresboekje.nlArticle: 113859
xx wrote: > a picture is worth a 1000 words: > > http://vhdlblog.blogspot.com/ > According to the pictures you post, you still haven't done a simulation. The last picture in your blog shows you are creating a testbench for your design (tbwf1.tbw) using some wizard included in the Xilinx software. I guess the software identifies y1 as an output, and it is asking for an input in the yellow zone, in order to verify the design when doing the simulation. You should input the expected outputs in the yellow zone, close the wizard pane, and launch Modelsim to perform the real simulation.(Should be available on the left pane) I guess the testbench wizard is too simple to be useful, but it is good as a starting point for designs like yours. Let me give you one little advice, search for some tutorials on the web, and spend some time reading them, the whole process of making an FPGA work may be counter-intuitive at times. Xilinx (and others) software, is known for being buggy sometimes, but I think you cannot blame Xilinx in a case as simple as this one. Best regards Josep DuranArticle: 113860
On 25 Dec 2006 06:21:25 -0800, "CMOS" <manusha@millenniumit.com> wrote: >1) Does any one know a better way of debugging? Simulation. >2) Is it common to write a simulation model for external >components(like CMOS sensor) so that the whole system can be simulated? The SRAM simulation model is almost certainly available online. For the sensor, I would expect to have to write a model. However Micron.com supply RAM models so it's worth looking for sensor models if you're using one of theirs. I'd use a constant array initialised with a test pattern for the sensor, though if I had a few hours to spare I'd write a reader for .bmp or .raw image files. Not strictly necessary but tends to impress the pointy haired types... - BrianArticle: 113861
Nico Coesel wrote: > "CMOS" <manusha@millenniumit.com> wrote: > > >>hi all, >> >>im in the process of designing and implementing a digital system on a >>spartan 3 FPGA. apart from the FPGA, im using two static RAM's and a >>CMOS image sensor for this design. Compared with other digital systems, >>this design is fairly simple. But im facing lot of trouble when it >>comes >>to debugging . Currently im using Chipscope pro for debugging, but the >>hassle of updating the connections and lack of block RAM for signal >>storage has forced me to investigate other possibilities for debugging. >>Since the design involves a CMOS sensor and a RAM, i cant do a full >>system simulation either. >> >>1) Does any one know a better way of debugging? > > > I've been using the following method for years: > I create a debug 'bus' inside the FPGA. I use a mux or tri-state > buffers which can put internal signals onto 8 or 16 output pins. This > allows me to monitor some essential signals from different modules and > track down where something goes wrong using a logic analyzer. Because > the debug bus grows together with the design, I can always monitor any > module connected to the debug bus in the fpga without need for > re-compiling. > > If a microcontroller is connected to an FPGA I make sure the > microcontroller can write/read data into memories or filters for test > purposes. During development, the microcontroller is very handy for > generating test patterns and verifying results. > > >>2) Is it common to write a simulation model for external >>components(like CMOS sensor) so that the whole system can be simulated? > > > I believe this is done very often but an error in the model will > introduce an error in your design. You'll still need to verify the > real-life timing on the external components with an oscilloscope or > logic analyzer. > This has been built into products from both Agilent and Tektronix to work with their logic analyzers. The Agilent product includes a mux and is tightly linked to the LA, so that when you switch the mux, the signal names show up on the LA screen. RBArticle: 113862
I have a problem when I try to use Xilkernel in a Spartan 3E. I
initialize the "xilkernel_main()", and all seems to be OK. The problem
is that I can't launch the first thread stored in the
"static_pthread_table".
Is there some manual???
Here is the output, the mss file and code for the application:
-- Entering main() --
XMK: Start
XMK: Initializing Hardware...
XMK: Initializing PIT device.
XMK: System initialization...
XMK: Enabling interrupts and starting system...
Idle Task
Idle Task
Idle Task
Idle Task
Idle Task
Idle Task
Idle Task
Idle Task
Idle Task
Idle Task
.........
BEGIN OS
PARAMETER OS_NAME = xilkernel
PARAMETER OS_VER = 3.00.a
PARAMETER PROC_INSTANCE = microblaze_0
PARAMETER stdout = RS232_DCE
PARAMETER stdin = RS232_DCE
PARAMETER systmr_dev = opb_timer_1
PARAMETER config_debug_support = true
PARAMETER verbose = true
PARAMETER sched_type = SCHED_PRIO
PARAMETER systmr_interval = 5
PARAMETER systmr_freq = 50000000
PARAMETER static_pthread_table = ((setup,1))
END
-------------
#include "xmk.h"
#include "os_config.h"
#include "sys/process.h"
#include "pthread.h"
#include "xparameters.h"
#include "stdio.h"
#include "stdlib.h"
#include "string.h"
//====================================================
void* setup();
int main() {
print("-- Entering main() --\r\n");
xilkernel_main();
}
void* setup()
{
print("Hello world \r\n");
return 0;
}
Article: 113863Antti Lukats wrote: > set XIL_IMPACT_ENV_LPT_BASE_ADDRESS=D880 > set XIL_IMPACT_ENV_LPT_ECP_ADDRESS=D800 > > like this, works! until that I was very upset that impact was not > able to talk to my pci superio card > > Antti OT - so Antti, did your kids get you a Virtex-5 for Christmas ? ;) -Dave PollumArticle: 113864
<topweaver@hotmail.com> wrote in message news:1167053078.622569.177710@f1g2000cwa.googlegroups.com... > Hi, > I have met some situations that people evaluate a design's complex > degree by asking "How many states does the state machine have". I suppose that would be one measure of complexity...not necessarily a very good one but a measure nonetheless. > I think any designs based on state machine can be rewritten to counter > style, While true, the obvious question would be "Why rewrite something?" > which does not have any state. Obviously you don't have a clue about what constitutes a 'state'. A counter certainly does have a state...the value of the counter at a particular time. > And in many times a combined mode > is used, which means only using a few states and each state has a > counter inside. Or in more general terms, state machines that fire off activity in other state machines (which may happen to be counters)...do it all the time when necessary. > By using state machine, syn_encoding value can be adjusted dynamically. > For example, when we cannot get the desired speed, we can set > syn_encoding to onehot. But when the speed is ok, is the counter style > enough? When code performs the function that one wants at the performance level that one requires and does not violate any timing then it really doesn't matter what style was used to get one there. What you should be aiming for after function and performance is supportability which is rather loosely the clearness of the source code for someone else (or yourself) to pick it up some point down the road and change it or improve it in some manner. Using state machines and counters properly where they are appropriate is one facet to that. KJArticle: 113865
"Dave Pollum" <vze24h5m@verizon.net> schrieb im Newsbeitrag news:1167154080.525417.37890@48g2000cwx.googlegroups.com... > > Antti Lukats wrote: >> set XIL_IMPACT_ENV_LPT_BASE_ADDRESS=D880 >> set XIL_IMPACT_ENV_LPT_ECP_ADDRESS=D800 >> >> like this, works! until that I was very upset that impact was not >> able to talk to my pci superio card >> >> Antti > > OT - so Antti, did your kids get you a Virtex-5 for Christmas ? ;) > -Dave Pollum > Hi Dave, humm - no? I have a ML501 to play with for some time already I posted to c.a.f. when I got it. Right now I am actually waiting for ML505 but that possible isnt arriving this year any more. for christmas I wished for me a stratix board (needed as reference board for microfpga "factory testing") and yesterday I was also promised an guess - a Virtex board also for microfpga testing - I need ref boards with all FPGA families. but those are all for me, not for kids. Andre got Unimat-1 http://www.thecooltool.com sure I need to supervise him a lot as he is only 4.5yrs old, but he really likes wood work so I hope he will have some fun too. at the moment there are too many other attractions so we havent done much with it yet. one reason also being me fun-working with MicroFpga's just got some AVR based ones to work with applications written with AVR Basic compiler and just a few minutes ago an i8080 based MicroFpga started to blink a LED with an c program compiled with DDS micro-C AnttiArticle: 113866
"CMOS" <manusha@millenniumit.com> wrote in message news:1167056485.058185.73520@a3g2000cwd.googlegroups.com... > hi all, > > im in the process of designing and implementing a digital system on a > spartan 3 FPGA. apart from the FPGA, im using two static RAM's and a > CMOS image sensor for this design. Compared with other digital systems, > this design is fairly simple. But im facing lot of trouble when it > comes > to debugging . Sounds like it wasn't so simple after all. > Currently im using Chipscope pro for debugging, but the > hassle of updating the connections and lack of block RAM for signal > storage has forced me to investigate other possibilities for debugging. Like simulation? Modelsim is a much more effective debug tool than any sort of in system debug tool for most problems. > Since the design involves a CMOS sensor and a RAM, i cant do a full > system simulation either. Your reasoning here does not follow at all. Your system could have much more to it than just a CMOS sensor and a RAM and it could still be modelled effectively. In fact, as a general rule, the larger the system around the thing you're designing becomes, the more important it becomes to model those other things.....in this particular case it would appear that a system with a sensor, RAM and FPGA is enough to warrant a more detailed simulation model than you provided. > > 1) Does any one know a better way of debugging? Simulation > 2) Is it common to write a simulation model for external > components(like CMOS sensor) so that the whole system can be simulated? Yes, unless you're implementing the same thing that you've done before and feel confident that you can do it again without more detailed simulation AND the cost to fixing a problem is low (for the case when you're wrong). This is usually the case with an FPGA, but not at all the case when you implement in a custom ASIC. > > > im guessing at least one of the above should exist, as making a real > world complex digital system with the methods im using currently will > be very time consuming and error prone. > Models for these external parts that make up the system that surround your design do not necessarily have to be the full blown model for the device. For example, an image sensor does not need to model the complete process of the conversion of photons into a data stream to be useful. It needs to only be as accurate as needed for you to debug (in a simulation environment) your design. If the FPGA design is simply collecting the data, doing some processing and storing the results to memory than that sensor model doesn't need to be anything more than a source of data. But the key thing you do is use the datasheet to model the handshaking that occurs in getting that data into the FPGA. These are the exact same datasheets that you were looking at when you did the FPGA design. Now look at them from the perspective of writing a functional model that implements this chip. Although there is the possibility of 'making the same mistake twice' when interpreting the data sheet, generally you'll find that when you're working on the model for the part you have a completely different perspective than when you were working on the FPGA design to interface to that part. Once you have that simulation model all up and running properly it's time to try it out in the real world. Depending on your skill you'll probably find some issues at that point where the real design still doesn't work. At that point, you pull out the in system debug tools, scope and logic analyzer, etc. not so much to debug the problem but to determine in what way your simulation model of the system is deficient and in need of enhancement. In other words, you're looking for the thing(s) that you missed or thought were not important or just didn't fully understand when you were taking those two views of the datasheet. Once you get a handle on what that is, you upgrade your model for the system to model this newly understood behaviour, leaving the design that you're working on unchanged. Once you upgrade your system model appropriately you should be seeing your design now fail in the same manner that it does in the real world. NOW you're ready to debug your design and then re-run the simulation to verify that the problem is fixed and THEN take it to the lab to see that it works in reality as well. As you get better at it, you tend to get better at generating parts models in part because whenever you look at a datasheet for something you'll be using in a new design you'll immediately be viewing it from the perspective of how to interface to it (knowledge which you'll use to implement your design) and from the perspective of how to create an effective model. Bottom line is that once you adapt this mindset you'll likely find that you're more effective debugging in the simulation environment where you have immediate access to any internal signal that you're interested in than it is to debug in the real world where access to internal signals usually comes at the cost of a design change (to bring out the internal signals) and an FPGA rebuild....and you still haven't fixed the problem, just brought out some signals....which could lead to bringing out more signals....and in the end when you have your design change to actually fix the problem you still don't have a way to test this change in the simulation envrionment ahead of time to see if you got it right. If the problem is not easily re-creatable this can be a major drawback. KJArticle: 113867
Antti Lukats wrote: > "Dave Pollum" <vze24h5m@verizon.net> schrieb im Newsbeitrag > news:1167154080.525417.37890@48g2000cwx.googlegroups.com... > > > > Antti Lukats wrote: > >> set XIL_IMPACT_ENV_LPT_BASE_ADDRESS=D880 > >> set XIL_IMPACT_ENV_LPT_ECP_ADDRESS=D800 > >> > >> like this, works! until that I was very upset that impact was not > >> able to talk to my pci superio card > >> > >> Antti > > > > OT - so Antti, did your kids get you a Virtex-5 for Christmas ? ;) > > -Dave Pollum > > > Hi Dave, > > humm - no? I have a ML501 to play with for some time already > I posted to c.a.f. when I got it. Right now I am actually waiting for > ML505 but that possible isnt arriving this year any more. > > for christmas I wished for me a stratix board > (needed as reference board for microfpga "factory testing") > and yesterday I was also promised an guess - a Virtex board > also for microfpga testing - I need ref boards with all FPGA families. > > but those are all for me, not for kids. My original question was what did the kids get _you_ for Christmas? I was joking that they got a Virtex-5 for you. > Andre got Unimat-1 > http://www.thecooltool.com > sure I need to supervise him a lot as he is only 4.5yrs old, > but he really likes wood work so I hope he will have some fun too. > at the moment there are too many other attractions so we havent > done much with it yet. > That Unimat-1 is a _cool_ tool! I wouldn't mind getting one to "play" with ;) I was curious how much it cost, but didn't find any information on the web site on how to purchase, not even a list of dealers. > one reason also being me fun-working with MicroFpga's > just got some AVR based ones to work with applications > written with AVR Basic compiler and just a few minutes > ago an i8080 based MicroFpga started to blink a LED > with an c program compiled with DDS micro-C > > Antti Tell me more about the i8080 based MicroFPGA. My first "home" computer used an 8080 CPU. -Dave PollumArticle: 113868
Hello, I've been doing some web researching on the next HDL and I've found interest in SystemVerilog, SystemC and EVHDL, and Confluence. In my shop we use Altera's AHLD language which is easy to learn and work in. A co-worker and I believe that AHDL will eventually die and maybe VHDL or Verilog too. But what will replace these HDL's is a good discussion topic. I wished there was something out their that was as easy as Altera's AHDL. joe Norbert Stuhrmann wrote: > Hello, > > jjlindula@hotmail.com schrieb: > > What is the next big HDL > > that will catch on and grab people from these different HDL > > backgrounds? Will VHDL, Verilog, AHLD, or SystemVerilog be replaced by > > something better? If so, what do you think it will be? > > Maybe SystemC for it's ability do to software/hardware co-design? > > Regards, > > NorbertArticle: 113869
<xx> wrote in message news:458f3891_4@mk-nntp-2.news.uk.tiscali.com... >> Is this your first simulation ever? Perhaps you are not using >> the tools properly. You have to save the testbench, make sure that > > The fact that I am getting a simulation indicates to me that I have > been using the tools correctly. The fact that the simulation is > not working indicate to me that xilinx tools do not work 'out of > the box' (if at all). Yes. I am just trying to determine if you are looking at the right screen. When I first used 6.2, I entered the waveform using the GUI, but I did not know that I needed to save that screen, (which by the way, will show all outputs as 0), and then run the simulation from the process window, which will open another screen. I am not running 8.2, however, I think other people would be complaining by now if they couldn't port a simple input to an output, even if it is clock. If there is a bug, perhaps you should try an asynchonous input to an output. Or add a dedicated clk input and try: test:process(clk) begin if(clk'event and clk='1') then y<=a; end if; end process; Good Luck, Brad Smallridge AiVisionArticle: 113870
<xx> wrote in message news:458f3b94$1_1@mk-nntp-2.news.uk.tiscali.com... >> 1. You should probably look up in the Xilinx documentation about what the >> yellow spikes are all about. > > These comment were made so that people know what I am looking at. > Reading the manuals will come later, after I know the xilinx tools do > work. After all, what good is it to learn a tool if it doesn't work? I'm betting that if you take the time to find out what is being indicated by the yellow spikes that it will likely be a lot clearer about what to do about it from there....just my guess >> 2. Take a look at the testbench code that was generated, (maybe post that > up >> here for all to see). > > I explained what I did, surely you can duplicate it and see what the > code is ? No, I don't use Xilinx for simulation, I use Modelsim. > >> 3. Maybe there is some problem with your simulator. >> >> I realize that the testbench code that you're using was generated by Mr. >> Wizard, but it should roughly look like the following....in fact maybe >> try >> copying the code below into your current testbench code file and comment > out >> or delete what is there and try simulating. If the code below works then >> you should look for differences between it and the Mr. Wizard generated >> testbench code (after finding out what yellow spikes are) and try to > figure >> out what is going on. > > OK I'll see if I can, but really, I don't want to be debugging for xilinx, > this > is their job. If it doesn't work, I'll wait for their next version. You're assuming that the problem is with the Xilinx tools. Maybe it is (seems to), but it's not clear one way or the other. I simply posted something that should be roughly like what Xilinx generated since you didn't post the testbench code itself. If you can run my testench code within Xilinx (or the Xilinx generated testbench in Modelsim) then this would tend to point to a problem with the Xilinx simulator....in which case, the suggestion would be to use some other simulator. KJArticle: 113871
Hi all,
I am reading some FIFO code by SystemVerilog. But there is a part of
code confused me. It seems to count push and pop pair appear times.
But if I have "push1 -> push2 -> pop1 -> pop2", coverage result will
give out 4 times or only 2 times theoretically? And why count this
number?
//--- Code start
property p_push_pop_sequencing;
@ (posedge clk) fifo_if.push |=> ##[0:$] fifo_if.pop;
endproperty : p_push_pop_sequencing
// coverage of sequences
cp_push_pop_sequencing : cover property (p_push_pop_sequencing);
//--- Code end
Any suggestions are welcome!
Best regards,
Shenli
Article: 113872Where I may assigned a special pins: Rocket IO Rx and Tx ?Article: 113873
I've already solved it.Article: 113874
> Just read the OPB specification (take a look at OPB bus pdf inside > SDK), it is really easy to write an OPB bus master How easy is it to make the OPB master co-exist in EDK with other OPB peripherials? I guess one has to make at least a "signal exposer" stub with the EDK tools, so that it integrates well. Is that right? Regards, Marc
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