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 a really exciting R&D role with a Media/Broadcast organisation in the Oxford area. If you have a solid background of VHDL digital design knowledge and fancy a move into a busy and exciting industry in Motion Capture then drop me your CV & contact details........ Salary range is =A333-38K + excellent benefits and a great working environment. My email is kh@waconsultants.com or 01392 666060 Kind regards Kevin Homeyard WAArticle: 123951
On Sep 7, 3:25 am, xenix <last...@gmail.com> wrote: > yes the MMU function of the PowerPC is ON. > > Regards What software are you running on the PowerPC? How does it set up the MMU? I could set it up with a 1:1 mapping of virtual to physical memory, but it could also set up some other mapping in which case you need to know the virtual address of the memory you are trying to access. Since you are running this in a simulator, you should be able to see everything that is going on. Do you see the PowerPC read from the expected address? Do you see your testbench writing the data to the BRAM? Regards, John McCaskill www.fastertechnology.comArticle: 123952
On Sep 6, 11:55 pm, eliben <eli...@gmail.com> wrote: > > We run the EMAC 8 bits wide at 125 MHz, and the PicBlaze at 62.5 MHz > > using a divided by two version of the EMAC clock. The PicoBlaze takes > > two cycles per instruction, and the packets we are offloading are a > > bit over 1KB, so we about 512 instructions to deal with an offloaded > > packet and other overhead. Dealing with a non-offloaded packet takes > > the shortest path through the code to keep the number of packets per > > second we can handle up. The network the data is on is tightly > > controlled, so there is very little on it that is not the protocol we > > are offloading, mostly just IGMP packets for dealing with the > > multicast groups, and they are at a very low rate. > > > You are correct in that we do not look at the entire packet with the > > PicoBlaze, just the header. Once it has determined that it wants to > > offload that packet, it then has a little bit more work to do to > > calculate addresses and load them into the DMA engine. To make sure > > that we do not drop packets, we just need to make sure that the > > longest path through the code takes less time than about how long it > > takes to receive a packet. We have a FIFO between the EMAC and the > > DMA engine, so we can smooth things out a bit. > > Thanks for the information. I must say I'm impressed with your design > - a great interoperability of logic, cores, small and large CPUs and > software. > > Eli Thanks for the compliment! I really like the PicoBlaze. It makes a great compliment to the PowerPC, and is very small. It is very good in this appication of being an IO processor. Regards, John McCaskill www.fastertechnology.comArticle: 123953
"John McCaskill" <jhmccaskill@gmail.com> wrote in message news:1189175806.333897.306440@r29g2000hsg.googlegroups.com... > > I would recommend against using the DCMs they way you are now. I made > the same mistake of using the FX output of one DCM to feed others. It > worked for quite a while, but as I added more stuff to the design, it > started to fail intermittently. If you do not want to use clock > enables as Symon suggested, consider using logic to generate the > clocks. As long as you can tolerate the jitter, you can take the > output of the clock generator and buffer it with a BUFG to distribute > it. Thanks for sharing your experience John. /MikhailArticle: 123954
Hi, 1. Based on the previous very benefitial discussions and my observation on the topics, I decide to recant the following claim: Whatever assertion onehot0() can do, 'orif' can do better. 2. In place of the above claim, I claim the following new one: Whatever assertion onehot() can do, it can do better working together with new keyword 'OIF'. 3. Rolin has indicated that orif has been used in 2006 version. 4. The following simplest example show why point 2 is justified. The more equations, the more complicated added statements distributed over the full entity to transfer the information to VHDL compiler. METHOD 1: if(TWindowLoad_E0_L_H and nC_BE_R0(3) = '0') then TWindow_3(10 downto 8) <= AD_R0(26 downto 24); OIF(TWindowLoad_E0_H_H and nC_BE_R0(7) = '0') then TWindow_3(10 downto 8) <= AD_R0(58 downto 56); end if; METHOD 2: current VHDL-2006. signal B2 : unsigned(1 downto 0); B2(0) <= '1' when TWindowLoad_E0_L_H and nC_BE_R0(3) = '0' else '0'; B2(1) <= '1' when TWindowLoad_E0_H_H and nC_BE_R0(7) = '0' else '0'; assertion onehot0(B2); if(B2(0) = '1') then TWindow_3(10 downto 8) <= AD_R0(26 downto 24); orif(B2(1) = '1') then TWindow_3(10 downto 8) <= AD_R0(58 downto 56); end if; 5. Thank you everone who paticipates on the topics. WengArticle: 123955
On 7 Sep, 10:20, lexluthor <hezhikuan2...@gmail.com> wrote: > I have designed a counter, it works like this: when the counter reach > a number , one of its output pins generate a high level signal, this > pin connects with the SOPC module. How can I achieve this goal : when > the pin's level changes, the PIO core generates a interrupt, in other > words, how can I register this type interrupt? > > Thank you very much! Edit the PIO component in SOPC Builder, and set it as follows: Basic settings Width: 1 Input ports only Input Options Synchronous capture - either edge Generate IRQ Edge Documentation for how to program the Nios to do what you want can be found here... http://www.altera.com/literature/hb/nios2/n2cpu_nii51007.pdfArticle: 123956
vasile wrote: > Hi there, > > I'm not very pleased reading the virtex 5 datasheet dealing with > Rocket IO transcievers. In fact the Xilinx datasheets are not > comprehensive and dificult to read. > > Every transciever bank has two lanes and a differential clock. > It seems the transciever can work with the regional clock too. See > page 66 of the http://direct.xilinx.com/bvdocs/userguides/ug196.pdf: > > "There are three ways to drive the CLKIN port (see Figure 5-3): > · Using an external oscillator to drive GTP dedicated clock routing > · Using a clock from a neighboring GTP_DUAL tile through GTP dedicated > clock > routing > · Using a clock from inside the FPGA (GREFCLK)" > > However the jitter requirements for the rocket IO clk is restrictive. > > "GREFCLK clocking is not recommended for most designs because of the > increased jitter introduced by the FPGA clock nets." Why the hell they > keep it ? > > Which will be your recommandation: using a suplementary low jitter > LVDS clock for every Rocket IO transciever or one clock to 3+1+3 > transcievers? If using a LVDS clock, one differential clock can be > shared succesfully between multiple transcievers ? (see page 69 of the > same datasheet). There is no information about the max jitter of such > configuration for the longest clk (the third transciever away from the > clk supply). > > thank you very much, > Vasile > There is no significant performance difference between using the REFCLK pins associated with the same GTP_DUAL site and driving using the dedicated routing resources in the GTP_DUAL column up to 3 GTP_DUAL sites away from the input location. All of the GTP_DUAL datasheet values are based on the worst case conditions. The 3rd choice of routing the input from a BUFG or BUFR source is available, but the datasheet performance specifications are not guaranteed in this configuration as jitter component of these nets are highly dependent on the specific design and operating conditions. If you find this unacceptable please do not use this option. There are designers that appreciate that this option is available and understand that they need to do additional verification that their final design meets their performance requirements. Ed McGettigan -- Xilinx Inc.Article: 123957
On Thu, 6 Sep 2007 17:23:39 -0500, "Dan K" <danielgkNOSPAM@visi.com> wrote: >Using linear adjustable regulators for VCCINT (1.25v), VCCIO (3.3v), and >VCCAUX (2.5v). VCCINT and VCCIO are dead on, but VCCAUX is 2.72v, 2.88v, >and 2.92v on the 3 boards I grabbed and measured. All boards seem to work >just fine. > >The regulator output voltage is controlled by just 2 resistors. When I >changed one of the resistors to lover the voltage a bit, VCCAUX did not >change. This leads me to believe that VCCAUX is somehow being "back" >powered from the Xilinx chip. These voltages are present like this before >the Xilinx chip has been programmed. I have not removed the regulator to >measure current yet. Another thought was to put a shotkey diode between the >regulator output and the load to see if the Xilinx really is powering >VCCAUX, but I thought I'd post and see if anyone else has come across this >issue. Half the I/O banks are 2.5v and half are 3.3v if that makes any >difference. > >Thanks - Dan > > Try adding a "dump" resistor from Vccaux to ground, and see if that pulls the voltage down. JohnArticle: 123958
Hi John. That's what I suggested in my posting yesterday. "Great minds think the same way" :-) Peter Alfke On Sep 7, 9:29 am, John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > On Thu, 6 Sep 2007 17:23:39 -0500, "Dan K" <danielgkNOS...@visi.com> > wrote: > > > > >Using linear adjustable regulators for VCCINT (1.25v), VCCIO (3.3v), and > >VCCAUX (2.5v). VCCINT and VCCIO are dead on, but VCCAUX is 2.72v, 2.88v, > >and 2.92v on the 3 boards I grabbed and measured. All boards seem to work > >just fine. > > >The regulator output voltage is controlled by just 2 resistors. When I > >changed one of the resistors to lover the voltage a bit, VCCAUX did not > >change. This leads me to believe that VCCAUX is somehow being "back" > >powered from the Xilinx chip. These voltages are present like this before > >the Xilinx chip has been programmed. I have not removed the regulator to > >measure current yet. Another thought was to put a shotkey diode between the > >regulator output and the load to see if the Xilinx really is powering > >VCCAUX, but I thought I'd post and see if anyone else has come across this > >issue. Half the I/O banks are 2.5v and half are 3.3v if that makes any > >difference. > > >Thanks - Dan > > Try adding a "dump" resistor from Vccaux to ground, and see if that > pulls the voltage down. > > JohnArticle: 123959
On Sep 7, 3:01 am, vasile <picli...@gmail.com> wrote: > On Sep 7, 8:00 am, Peter Alfke <al...@sbcglobal.net> wrote: > > > On Sep 6, 9:03 pm, Jim Granville <no.s...@designtools.maps.co.nz> > > wrote:> Peter Alfke wrote: > > > > >>>The regulator output voltage is controlled by just 2 resistors. When I > > > >>>changed one of the resistors to lover the voltage a bit, VCCAUX did not > > > >>>change. This leads me to believe that VCCAUX is somehow being "back" > > > >>>powered from the Xilinx chip. These voltages are present like this before > > > >>>the Xilinx chip has been programmed. I have not removed the regulator to > > > I should have expressed this better: Use the extra pull-down resistor > > just as an experiment to see whether the problem really is reverse > > current going into the regulator, or is something else. Just > > temporarily, just attach the resistor lightly, by hand if possible... > > Peter Alfke > > Unfortunately increasing the power dissipation with sinking/sourcing > LDO on VCCAUX or external loads can't be the final solution. If there > is a leackage current path from VCCIO to VCCAUX that must be founded > and supressed somehow. > Using series schottky between VCCAUX and FPGA will drop the output > voltage to VCCAUX - (0.3V...0.7V) depending on load current and diode > type. > > Vasile You should make sure that no VCCAUX relative pins are hooked to VCCIO without a resistor otherwise any fix can blow up the esd diodes. Then, if you really need to save a couple of milliwatts, power the VCCCORE regulator from VCCAUX, this will suck the backrush of current right into another power supply instead of into a resistor. It is no coincidence that 1.2v LDO regulators are designed to run on 2.5v. Cheers Jon PryArticle: 123960
>This is exactly why direct MAC communication is undesirable here. >Tying the sender to the receiver's MAC address as a constant isn't >good engineering. > >> (saves doing ARP, but ARP could also be done in external software >> and the result written to the FPGA). > >Indeed. ARP needs to be done only once in a while anyway, so it can be >done by a slow software program. I think you are missing the big picture. Before you can do ARP, you have to have an IP Address. Where did that come from? Why not provide the MAC address through the same path? If you have a send-only application, you don't need any protocol stack. Just fill in a few constants and blast away. Yes, it might be convenient to have some software around. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 123961
The next complication is
>generating the CRC for UDP, but that is optional. The ethernet
>CRC has to be generated in either case.
UDP doesn't have a CRC. There is a software checksum, but it's
designed to be easy to compute with typical CPUs. There is
a clean way to say "none".
Just for the record...
The Ethernet CRC is not really necessary. It's getting kludgy
to avoid it, but it can be done. The trick is to get the
adapter on the receive side to give you the bad packet too.
That may be hard/impossible on some of them. I haven't tried
to do it in ages. It used to be a common hack for debugging.
--
These are my opinions, not necessarily my employer's. I hate spam.
Article: 123962You're so kind, thank you very much!Article: 123963
When I Run the NiosII project, there is sometimes this error info. in the console: nios2-terminal: exiting due to ^D on remote But Why? it is relative with the pointer ? Thank you very much!Article: 123964
On Sep 7, 9:31 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > >This is exactly why direct MAC communication is undesirable here. > >Tying the sender to the receiver's MAC address as a constant isn't > >good engineering. > > >> (saves doing ARP, but ARP could also be done in external software > >> and the result written to the FPGA). > > >Indeed. ARP needs to be done only once in a while anyway, so it can be > >done by a slow software program. > > I think you are missing the big picture. > > Before you can do ARP, you have to have an IP Address. Where > did that come from? Why not provide the MAC address through > the same path? The IP address can be statically allocated. If my recipient changes the computer during the runtime of the system (years), his MAC changes, but not his IP. EliArticle: 123965
On Sat, 08 Sep 2007 06:10:08 -0000, eliben <eliben@gmail.com> wrote: >On Sep 7, 9:31 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal >Murray) wrote: >> >This is exactly why direct MAC communication is undesirable here. >> >Tying the sender to the receiver's MAC address as a constant isn't >> >good engineering. >> >> >> (saves doing ARP, but ARP could also be done in external software >> >> and the result written to the FPGA). >> >> >Indeed. ARP needs to be done only once in a while anyway, so it can be >> >done by a slow software program. >> >> I think you are missing the big picture. >> >> Before you can do ARP, you have to have an IP Address. Where >> did that come from? Why not provide the MAC address through >> the same path? > >The IP address can be statically allocated. If my recipient changes >the computer during the runtime of the system (years), his MAC >changes, but not his IP. You could quite safely use some random private IP address, such as 192.168.123.45 as the target address and require the receiver to specify this IP address on one of the their Ethernet adaptors. You just need to do the ARP translation to get the MAC address. If the target PC is swapped, you just have to redo the ARP translation at startup. This is quite sufficient in any non-redundant system. PaulArticle: 123966
eliben wrote: > On Sep 7, 9:31 pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal > Murray) wrote: (snip) >>Before you can do ARP, you have to have an IP Address. Where >>did that come from? Why not provide the MAC address through >>the same path? > The IP address can be statically allocated. If my recipient changes > the computer during the runtime of the system (years), his MAC > changes, but not his IP. The IP address can be static to the FPGA, in a programmable register written into be an external processor doing ARP. You can also use BOOTP to load the hosts own IP address, with the destination IP address as one of the BOOTP options. That can all be done in an external processor (or processor internal to the FPGA). -- glenArticle: 123967
Hi, this is because your design send a ^D char to the JTAG UART,which is interpreted as 'quit' by nios2-terminal. You should now find if ^D is expected from you target board or if it erroneous (noise problem ?). Hope this will hep. Regards. -- --------------------------------- --- -- - Posted with NewsLeecher v3.9 Beta 2 Web @ http://www.newsleecher.com/?usenet ------------------- ----- ---- -- -Article: 123968
Hi, I don't know but i would recommend you a very good place where you can post your question: http://www.niosforum.com Regards. -- --------------------------------- --- -- - Posted with NewsLeecher v3.9 Beta 2 Web @ http://www.newsleecher.com/?usenet ------------------- ----- ---- -- -Article: 123969
"devices" <me@home> wrote in message news:46e14f98$0$4784$4fafbaef@reader4.news.tin.it... > Target Device: CYCLONE > > My project allocates some RAM and initializes > it by an Intel Hex File. The Simulator correctly > shows the initialized data. > > <CODE> > > lpm_ram_dq ram > ( > .address (_addr), > .q (_dout), > .data (_di), > .we (_we), > .inclock (clk), > .outclock (!clk) > ); > > defparam ram.lpm_width = 8; > defparam ram.lpm_widthad = 11; > defparam ram.lpm_file = "-----.hex"; > defparam ram.lpm_indata = "REGISTERED"; > defparam ram.lpm_outdata = "REGISTERED"; > > defparam ram.lpm_address_control > = "REGISTERED"; > > defparam ram.lpm_hint = > "ENABLE_RUNTIME_MOD=YES, INSTANCE_NAME=AAAA"; > > </CODE> > > I'm not sure the synthesizer/programmer initialize > the sram on the real device. I thought > > 1) i could check it out by using Quartus II > "In-System Memory Content Editor". > > I also thought > > 2) that by inspecting the ram content i can check > whether my design is working as required. > > But if i enable the ISMC Editor (the last defparam), > the compiler gives the following error: > > "Insufficient resources available on RAM to use > In-System Memory Content Editor" > > I guess that for "Device Family" reasons the compiler > ends up using altsyncram: > > lpm_ram_dq:ram > __altram:sram > ____altsyncram:ram_block > > The error message doesn't say which are the > missing resources. I guess the ram needs to be > a dual port one. I use one port and the Editor > uses the other. If i disable ENABLE_RUNTIME_MOD > i get a single port. I thought the other port is left > unused, but now i'm not sure the chain: > > lpm_ram_dq->altram->altsyncram > > sets up for a dual port usage at all. > > Even though i declare a single port, i thought > the synth adds the second one as soon as it > realizes the Runtime Mod is enabled. Altsyncram > has Dual Port, after all. > > Or is the issue about something else? > > It was something else. I fixed the issue last night and i've just tested the ram. Several lines above the error there was another red line saying that no clock was available. I gave up the "outclock" and tied it to vcc, unregistering the output (fortunately this posed no issue to the design). The compiler was happy and started dancing to the rhythm of the clock. I can clearly see that the .hex file is correctly preloaded.Article: 123970
I've been struggling for weeks to get sdram to work correctly on a newly designed board. I was hoping that someone might have some suggestions to help me out with my struggle here. This is what I am seeing: I am using EDK 8.1 to build a Microblaze system with a sdram controller. The memory is a micron 48LC16M8A2tc-75 part. I have verified that writes look correct using chipscope. I've carefully looked at all the parameters for the sdram in the EDK and verified in chipscope that I'm meeting the timing requirements on each parameter for the write side. So I feel pretty confident that everything looks good on the write side. But I cannot verify what is happening on the read side because chipscope does not allow me to see the input from the sdram chip. I'm pretty sure that the problems I am seeing are happening on the read side. I'm using XMD to test the memory by sending mwr and mrd commands. Since my chip has an 8 bit data bus, when I do a mwr 0x21000000 0x01020304 and watch what happens in chipscope I see the following: -The column and row get set correctly for the bank 0, column 0, row 0. -Four bytes are written sequentially 0x01, 0x02, 0x03, 0x04 and DQM is active the entire time. -All the timing looks right. When I do a read using mrd 0x21000000 I get back 0x01010101. If I do a mwr 0x21000000 0x02030405 (a 32bit write) and then a mrd 0x21000000 I will get back 0x02020202. I always get back the first byte that was written in the four byte sequence. If I do a mwr 0x21000001 0xFF 1 b (8 bit write) and a mrd 0x21000001 1 b then I will get back whatever was written to 0x21000000. This behavior is consistent across all addresses. Any reads or writes will always do an active command, then a read/ write command which will set the beginning address and then will send four bytes, the 1st byte for the initial address and then 3 more bytes for the next 3 addresses using NOP's in burst mode. So there are a third of the addresses in the address space that I cannot directly address. I cannot find the setting anywhere that allows me to do a single beat operation as mentioned in the data sheet. It always defaults to burst mode. The reason that I believe that the problem is on the read side is because when I power up the device the sdram should have random data in it. When I do a mrd on random addresses it will always come back as a random number repeated four times, like 0xADADADAD or 0x04040404 etc. If I'm not mistaken, the chances of always getting the same number in four different addresses is pretty unlikely. It should be random numbers for all four addresses. Does anyone have any insight into what is happening here? The two questions that I have in addition are: -Is there anyway to see the input from the sdram chip using chipscope. I tried to look at the OPB bus but that did not show any useful information. It just showed the four same bytes showing up on the bus. -Is there a way to change how the sdram controller works so when I do a mwr 0x21000003 0xFF 1 b it actually selects bank 0, row 0, column 3 and sends 1 byte instead of selecting bank 0, row 0, column 0 and then sending 4 FF bytes while putting DQM active on the 3rd byte. That way it would work slower but at least I can verify that the problem is with burst writes and not something else. Any help is sincerely appreciated, John.Article: 123971
"John_H" <newsgroup@johnhandwork.com> wrote in message news:13e07ln903ocg34@corp.supernews.com... > <aclegg1986@googlemail.com> wrote in message > news:1189090543.879764.76630@r29g2000hsg.googlegroups.com... >> Hi, > It's because of the simulation/synthesis mismatch that I've very dutifully > added those pitifully unnecessary async resets throughout my recent > designs except for the logic that I *know* will perform better (where > performance is needed) without the constraints of an async reset. Not following why you would do this and just what simulation/synthesis mismatch you're talking about. A flip flop that doesn't *need* to be reset will be an unknown so if the simulation says that some output is an 'X', but the design functionally performs what you want it to do in simulation even with the 'X', then there is no mismatch that needs to be resolved...and certainly not by adding an otherwise unneeded reset. One such situation would be an output interface that has say a data bus and an output data qualifier. If the data bus is 'X' but the output data qualifier is false then there should be no compelling reason to put resets on the data bus outputs. I realize there a bunch of other scenarios, but there is generally no requirement for all storage elements in a design to get into a known particular state at 'reset'. If the simulation model for the system works as intended and passes all testbench tests then you've properly initialized all of the storage elements that are required. This is true whether doing a sim based on the original source code or the post-route sim (assuming that you've also passed static timing analysis). KJArticle: 123972
KJ wrote: > "John_H" <newsgroup@johnhandwork.com> wrote in message > news:13e07ln903ocg34@corp.supernews.com... >> <aclegg1986@googlemail.com> wrote in message >> news:1189090543.879764.76630@r29g2000hsg.googlegroups.com... >>> Hi, >> It's because of the simulation/synthesis mismatch that I've very dutifully >> added those pitifully unnecessary async resets throughout my recent >> designs except for the logic that I *know* will perform better (where >> performance is needed) without the constraints of an async reset. > > Not following why you would do this and just what simulation/synthesis > mismatch you're talking about. A flip flop that doesn't *need* to be reset > will be an unknown so if the simulation says that some output is an 'X', but > the design functionally performs what you want it to do in simulation even > with the 'X', then there is no mismatch that needs to be resolved...and > certainly not by adding an otherwise unneeded reset. > > One such situation would be an output interface that has say a data bus and > an output data qualifier. If the data bus is 'X' but the output data > qualifier is false then there should be no compelling reason to put resets > on the data bus outputs. I realize there a bunch of other scenarios, but > there is generally no requirement for all storage elements in a design to > get into a known particular state at 'reset'. If the simulation model for > the system works as intended and passes all testbench tests then you've > properly initialized all of the storage elements that are required. This is > true whether doing a sim based on the original source code or the post-route > sim (assuming that you've also passed static timing analysis). > > KJ If one designs with programmable logic, the simulation will not provide adequate results with all Xs. The flops that don't need reset that we're talking about are the ones that configure to known states and those known states are necessary for a starting point for synthesis to begin from. A count incrementing from X to X doesn't provide the simulation results needed. It's not "all storage elements" that I want to have brought to a known state for simulation, it's the registers that have known power-up states that the simulation is unaware of. The discussion is about adding async reset to establish unequivocally what the power up state is for both simulation and synthesis. I'm looking forward to the day when I can assign my registers, SRLs, and simple ROMs and RAMs initial values by declaring my vectors with initial states. My synthesis tool *still* doesn't support "reg [3:0] myFour = 4'h4;" style syntax, ignoring the construct. XST has supported the construct but didn't do a great job with SRLs a while back, breaking the SRL at each binary 1 in the initialization. Initial blocks and declaration initial statements would make life *so* much easier for me. Assuming, that is, that the synthesizer doesn't implement gratuitous "optimizations" that are inefficient in the end. I just ask too much of my tools, sometimes. - John_HArticle: 123973
"John_H" <newsgroup@johnhandwork.com> wrote in message news:BoGEi.1024$cy3.561@trndny03... > KJ wrote: > > The flops that don't need reset that we're talking about are the ones that > configure to known states and those known states are necessary for a > starting point for synthesis to begin from. A count incrementing from X > to X doesn't provide the simulation results needed. OK, then we're talking about synthesis support (or lack thereof) for initial values in either (or both) the physical part and the post-route simulation model (duh...it was the name of the post)....I agree, that can be spotty in which case you open a service request to the supplier for producing a sim model that doesn't mimic the correct power up/end of configuration condition. They really won't have much of a leg to stand on for why they don't correctly model the specified behaviour. When enough people grumble about it, it could get fixed, if nobody grumbles they definitely will not fix it. Of course, in the mean time you design in the resets that you were talking about so you can get your job done. > I'm looking forward to the day when I can assign my registers, SRLs, and > simple ROMs and RAMs initial values by declaring my vectors with initial > states. My synthesis tool *still* doesn't support "reg [3:0] myFour = > 4'h4;" style syntax, ignoring the construct. XST has supported the > construct but didn't do a great job with SRLs a while back, breaking the > SRL at each binary 1 in the initialization. Initial blocks and > declaration initial statements would make life *so* much easier for me. > Assuming, that is, that the synthesizer doesn't implement gratuitous > "optimizations" that are inefficient in the end. > > I just ask too much of my tools, sometimes. > As do we all....sigh. KJArticle: 123974
I set the SignalTap memory depth to 16K and would like to collect exactly that many data points after the trigger. However, it seems SignalTap will only stop collecting (and therefore overwriting the older data) unless I manually hit the STOP button. I tried both the circular and segmented options, but did not see any difference. Thanks.
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