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
Tommy Thorn wrote: > Mike Treseler wrote: > > santanu wrote: > > > > > The program compiled fine, and the bitstream was generated > > > and downloaded successfully. But the problem is now, how > > > do I see the memory where the result is supposed to be present? > > > > Either run a simulation or put a probe > > on the c_lower pins. > > I think he needs more help than that. > > Santanu, only a subset of Verilog is synthesizable. Initial contructs > in particular have no meaning for synthesis and your example is pretty > nearly a no-op. First of all, thank you both for replying. Mike, did you mean a logic analyser probe? If so, we don't have a logic analyser here as yet. Simulation is not a problem, but I wanted to see the whether the results were actually stored in the memory. Tommy, as you said, if the initial construct is non synthesizable, then how is a pin set to a default value using verilog? In any case, isn't the memory location supposed to store the multiplication result? In trivial cases, I can see the results by means of turning the two LEDs on or off, but for a 64 bit multiplied value, apparently I have no other way to see the result, other than storing it in memory and reading it in some way, since this board (the Xilinx Virtex II based Microblaze and Multimedia Demonstration Board) has no GPIO pins. There are audio, video, ethernet, rs232 ports, but they require respective controllers to access them, which I am currently not in a position to write. I was trying to use the rs232 code from www.opencores.org, but I could not get it working as yet, especially since they use a 'wishbone' interface, which I know nothing about. Regards, SantanuArticle: 106276
Guru wrote: > Hi all, > > I am building EDK peripheral with FIFO Coregen 2.3 included. In ISE > peripheral project everything is working fine (FIFO netlist is included > and properly sinthesized and built), but in EDK flow every time i get > an error during bulid: "unresolved FIFO - missing netlist or pin > misspeling can cause this..." > > I have of course included in MPD: > OPTION IMP_NETLIST = TRUE > OPTION STYLE = MIX > OPTION RUN_NGCBUILD = TRUE > > and in BDD file: > Files > async_fifo.edn > async_fifo_fifo_generator_v2_3_fifo16_1.edn > > and in PAO FIFO wrapper: > lib peripheral_v1_00_a async_fifo vhdl > > > but the problem persists (and eating my nerves :( ). Files are not > properly copied (included) to project implementation directory. I > managed to resolve the problem by manually copying netlists to the imp > directory, but that is not what I want. > > My methodology obviously doesn't work. Does anyone knows the proper > procedure to fix this (or is maybe willing to give an example)? > > Cheers, > > Guru > Every time I create a new EDK peripheral which includes cores from Coregen it seem to be a struggle to get the ngdbuild tool to find the cores. The only think I can think of is that your netlist-catalog is either misspelled or that your bbd file has the extension bdd (as you have written in your post). If that is not the case you can try to put the netlist names on one line as below. Files async_fifo.edn, async_fifo_fifo_generator_v2_3_fifo16_1.edn Regards -- ----------------------------------------------- Johan Bernspång, xjohbex@xfoix.se Research engineer Swedish Defence Research Agency - FOI Division of Command & Control Systems Department of Electronic Warfare Systems www.foi.se Please remove the x's in the email address if replying to me personally. -----------------------------------------------Article: 106277
Many of the Xilinx pcores, e.g. ll_temac use a TCL script to check if a coregen generated netlist already exists and to generate one it if it doesn't exist. /Mikhail "Guru" <ales.gorkic@email.si> wrote in message news:1155207923.790368.106990@m73g2000cwd.googlegroups.com... > Hi all, > > I am building EDK peripheral with FIFO Coregen 2.3 included. In ISE > peripheral project everything is working fine (FIFO netlist is included > and properly sinthesized and built), but in EDK flow every time i get > an error during bulid: "unresolved FIFO - missing netlist or pin > misspeling can cause this..." > > I have of course included in MPD: > OPTION IMP_NETLIST = TRUE > OPTION STYLE = MIX > OPTION RUN_NGCBUILD = TRUE > > and in BDD file: > Files > async_fifo.edn > async_fifo_fifo_generator_v2_3_fifo16_1.edn > > and in PAO FIFO wrapper: > lib peripheral_v1_00_a async_fifo vhdl > > > but the problem persists (and eating my nerves :( ). Files are not > properly copied (included) to project implementation directory. I > managed to resolve the problem by manually copying netlists to the imp > directory, but that is not what I want. > > My methodology obviously doesn't work. Does anyone knows the proper > procedure to fix this (or is maybe willing to give an example)? > > Cheers, > > Guru >Article: 106278
Peter, the way you describe your problem, there is (and there can be) no solution, if you switch asynchronously between two unknown clocks. You will lose an edge, since you cannot use edges that are very close to each other. Assume the two rising edges are 50 ps apart. Are they two edges or one? How's about 1 ns, etc.? You must be willing to lose an edge, and the"six easy pices" circuit is your solution. Cheers Peter Alfke, Xilinx ================== PeterC wrote: > I have two clocks which are relatively synchronous (ie. the frequencies > are exactly the same because the originate from the same master clock), > but one of the clocks is shifted in phase, and this phase shift is > dynamically variable and may be up to one whole period. > > I need to switch between these two clocks, but without losing rising > edges. From my experiments with BUFGMUXs, I appear to be losing a > rising edge (post PAR timing simulation). > > I believe Peter's circuit in his Six Easy Pieces may also cause an edge > to be lost. Peter writes "Any clock-switching starts when the > originally selected clock goes Low, and the Output Clock then stays Low > until the newly selected clock has first gone Low and then High again." > > I realize that asynchronous clock multiplexing has been covered many > times in the group, but I simply can't find a good solution to my > specific problem. > > Peter.Article: 106279
Thomas Entner schrieb: > Hi Antti, > > which speed-grades are you talking about? Slowest or fastest? > > Thomas > Thomas, the fmax info for each FPGA SoC system should be really checked case by case, and 75MHz is generically good choice. it may be possible to get 100Mhy timing ok in slowest speed and it maybe that frequencies below 100MHz make problems in highest speed grade. so make the system, add the peripheral and run synthesis to see what goes. AnttiArticle: 106280
PeterC, The best I was able to do was to switch using a plain 2:1 multiplexer. But I followed this with a 'clean up PLL'. That way, there was no possibility of ever having a bad clock cycle at the output of the PLL. If the input to the PLL just goes to a simple XOR phase detector, the worst that can happen is you build out one clock cycle, either + or -, over time, sometimes (not always) when you switch. Since this was used throughout the synchronization and timing systems we were building, the equipment met Bellcore requirements as a sync source. The requirement was that if you had to slip or swallow a clock cycle, it happened over a long enough period of time that no bit errors were created in the entire central office, anywhere. Eventually, if you accumulate an entire frame of 193 bits (old T1 design made all switch buffers no more than two frames, and many were one frame) you would drop an entire frame from every line in the central office (they didn't like that at all). Since the switch of clocks was asynchronous, and you could slip or swallow an entire clock period if the phases were exactly wrong; on average, you did not gain nor lose any bits in the buffers (all was well). I do not think there is any way possible to do what you are asking, as all of my competition did no better, either (and many did worse). Austin Aside: the 193 bit buffer is also related to the total allowed delay across a switch: three 125 uS periods (three frames of 193 bits at T1). At faster rates, with larger frames, the buffers are obviously allowed to be larger than 193 bits. PeterC wrote: > I have two clocks which are relatively synchronous (ie. the frequencies > are exactly the same because the originate from the same master clock), > but one of the clocks is shifted in phase, and this phase shift is > dynamically variable and may be up to one whole period. > > I need to switch between these two clocks, but without losing rising > edges. From my experiments with BUFGMUXs, I appear to be losing a > rising edge (post PAR timing simulation). > > I believe Peter's circuit in his Six Easy Pieces may also cause an edge > to be lost. Peter writes "Any clock-switching starts when the > originally selected clock goes Low, and the Output Clock then stays Low > until the newly selected clock has first gone Low and then High again." > > I realize that asynchronous clock multiplexing has been covered many > times in the group, but I simply can't find a good solution to my > specific problem. > > Peter. >Article: 106281
> deriving the SCLK from the LSB of a counter in the FPGA. But this isn't > working. Did you succed now with the design? Did you try the DDR architecture (assuming full fpga clock speed is needed here ?)Article: 106282
Quoth Antti > The claims for microblaze and ppc fmax have to be read with some > precaution. In April 2006 Xilinx claimed 200MHz fmax for MicroBlaze 4 > in Virtex-4. Maybe it is possible under some conditions but for me it > sounds like wishfull thinking. Well I bet MB 5 in Virtex5 in > "ultracontroller" like setup may run at 200MHz - this is more > realistic. But some small medium MB.4 system in Virtex-4 does not reach > 200MHz (at least with current XST synthesis, maybe XST will improve > timing once again and get better performance). Similarly the 450MHz PPC > operation defenetly means operation from onchip caches only with no bus > peripherals at all. So for real applications you better calculate with > 300MHz cpu clock. Thanks Antti - good to know :-) Simon.Article: 106283
Peter Alfke wrote: > Peter, > the way you describe your problem, there is (and there can be) no > solution, if you switch asynchronously between two unknown clocks. > You will lose an edge, since you cannot use edges that are very close > to each other. > Assume the two rising edges are 50 ps apart. Are they two edges or one? > How's about 1 ns, etc.? > You must be willing to lose an edge, and the"six easy pices" circuit is > your solution. > Cheers > Peter Alfke, Xilinx > ================== > PeterC wrote: > > I have two clocks which are relatively synchronous (ie. the frequencies > > are exactly the same because the originate from the same master clock), > > but one of the clocks is shifted in phase, and this phase shift is > > dynamically variable and may be up to one whole period. > > > > I need to switch between these two clocks, but without losing rising > > edges. From my experiments with BUFGMUXs, I appear to be losing a > > rising edge (post PAR timing simulation). > > > > I believe Peter's circuit in his Six Easy Pieces may also cause an edge > > to be lost. Peter writes "Any clock-switching starts when the > > originally selected clock goes Low, and the Output Clock then stays Low > > until the newly selected clock has first gone Low and then High again." > > > > I realize that asynchronous clock multiplexing has been covered many > > times in the group, but I simply can't find a good solution to my > > specific problem. > > > > Peter. Hi Peter As much as I dislike disagreeing with the renowned Peter Afke, one can switch between two asynchronous clocks (in this case as the frequencies are locked but the phase differs, and can change). I once designed a hitless switch (in telecom, for DS3) to switch between two source synchronous bit streams, with a phase asynchronicity attributable to path delay which was variable, that did not miss a bit during switching between space diversity receivers (hence hitless :) That's important in DS3, of course, as missing a bit has a major hit on framing, so frame relock is then necessary, which was deemed unacceptable. It takes a little work but can be done. In that case, I conditioned both the clocks _and_ the data stream (which could have a significant bit position offset), which may be overkill here. Without knowing more about the specifics of PeterC's requirements, (both for clock rates and phase rate of change apart from overall structure) it's hard to be specific. I will also mention I used discrete and analog techniques (ECL for the logic) - this was in the days before really fast VLSI (or even really fast LSI for that matter, excepting ECL), but the same techniques could be used simply transposed completely into the digital domain. Maybe I'll chew over it over the next couple of days, run up some code over the weekend and post it (warning : I prefer Verilog ;) Maybe :) Cheers PeteSArticle: 106284
I am having a hard time getting ISE/XST to ignore clock skew between
two clock domains from an asychronous FIFO generated from CoreGen. Why
is the tool not ignoring this automatically? Here is the error after
Map:
<SNIP>
================================================================================
Timing constraint: TS_CLKFB_OSC = PERIOD TIMEGRP "CLKFB_OSC" TS_CLK1_FB
HIGH 50%;
1681 items analyzed, 26 timing errors detected. (26 setup errors, 0
hold errors)
Minimum period is 3892.500ns.
--------------------------------------------------------------------------------
Slack: -1.036ns (requirement - (data path - clock path
skew + uncertainty))
Source:
fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 (FF)
Destination:
fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8 (FF)
Requirement: 0.002ns
Data Path Delay: 1.038ns (Levels of Logic = 0)
Clock Path Skew: 0.000ns
Source Clock: fx_clk rising at 9607.498ns
Destination Clock: CLK_OSC rising at 9607.500ns
Clock Uncertainty: 0.000ns
Timing Improvement Wizard
Data Path: fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8 to
fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8
Delay type Delay(ns) Logical Resource(s)
---------------------------- -------------------
Tcko 0.568
fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp_8
net (fanout=1) e 0.100
fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmp<8>
Tdick 0.370
fifoadc2_inst/BU2/U0/flblk/clkmod/rdx/pntr_tmpx_8
---------------------------- ---------------------------
Total 1.038ns (0.938ns logic, 0.100ns route)
(90.4% logic, 9.6% route)
</SNIP>
I have a 9.5 ns clock input feeding the write port, and a 9.5*21/19 ns
clock on the read port. I have a TIG setup as follows:
<SNIP>
NET "CLK1_FB" TNM_NET = "CLK1_FB";
TIMESPEC "TS_CLK1_FB" = PERIOD "CLK1_FB" 7.5 ns HIGH 50 %;
PIN "U0_DCM.CLK0" TNM = "DCM_CLK0";
PIN "U0_DCM.CLKFX" TNM = "DCM_CLKFX";
TIMESPEC "TS_CLK0_2_CLKFX" = FROM "DCM_CLK0" TO "DCM_CLKFX" TIG;
#Asynch FIFO clock domains
</SNIP>
CLK1_FB drives the CLKIN input of the DCM, so it too is 9.5 ns. Any
ideas? I'm lost....
Thx,
-Brandon
Article: 106285Jeremy Price wrote: > Hello all, > > I am working with the Xilinx ML403 board and I am trying to find some documentation about the UDP Multicast performance for the board. Does anyone have any pointers? > > Thanks www.xilinx.com/gsrd has some numbers (basically line rate on 1G) for TCP throughput. You could probably extrapolate from that.. /SivaArticle: 106286
Wow, three Peters in various stages of disagreement... I suppose it depends on the basic assumptions. In "6 easy...", I assumed a worst case, where the switching is asynchronous, and the two clocks have no known phase of frequency relationship. In today's posting the two frequencies are identical, but the phase relationship is unknown. Let's assume the decision to switch is synchronous with the presently used clock. Then you have to make sure that the to-be-acquired rising clock edge is at least a clock period later (otherwise I can get in timing trouble). That assumption inherently loses one clock transition (except in the extreme case when both phases are aligned. If you change the rules, and acept a shorter clock cycle during the switch-over, things are different, but you now must put a limit on it, otherwise you get two clock edges that are very close (and how close is too close ?) That's why I wrote my skeptical remarks. Back to the Peters Peter Alfke. ===================== PeteS wrote: > Peter Alfke wrote: > > Peter, > > the way you describe your problem, there is (and there can be) no > > solution, if you switch asynchronously between two unknown clocks. > > You will lose an edge, since you cannot use edges that are very close > > to each other. > > Assume the two rising edges are 50 ps apart. Are they two edges or one? > > How's about 1 ns, etc.? > > You must be willing to lose an edge, and the"six easy pices" circuit is > > your solution. > > Cheers > > Peter Alfke, Xilinx > > ================== > > PeterC wrote: > > > I have two clocks which are relatively synchronous (ie. the frequencies > > > are exactly the same because the originate from the same master clock), > > > but one of the clocks is shifted in phase, and this phase shift is > > > dynamically variable and may be up to one whole period. > > > > > > I need to switch between these two clocks, but without losing rising > > > edges. From my experiments with BUFGMUXs, I appear to be losing a > > > rising edge (post PAR timing simulation). > > > > > > I believe Peter's circuit in his Six Easy Pieces may also cause an edge > > > to be lost. Peter writes "Any clock-switching starts when the > > > originally selected clock goes Low, and the Output Clock then stays Low > > > until the newly selected clock has first gone Low and then High again." > > > > > > I realize that asynchronous clock multiplexing has been covered many > > > times in the group, but I simply can't find a good solution to my > > > specific problem. > > > > > > Peter. > > Hi Peter > > As much as I dislike disagreeing with the renowned Peter Afke, one can > switch between two asynchronous clocks (in this case as the frequencies > are locked but the phase differs, and can change). > > I once designed a hitless switch (in telecom, for DS3) to switch > between two source synchronous bit streams, with a phase asynchronicity > attributable to path delay which was variable, that did not miss a bit > during switching between space diversity receivers (hence hitless :) > > That's important in DS3, of course, as missing a bit has a major hit on > framing, so frame relock is then necessary, which was deemed > unacceptable. > > It takes a little work but can be done. In that case, I conditioned > both the clocks _and_ the data stream (which could have a significant > bit position offset), which may be overkill here. > Without knowing more about the specifics of PeterC's requirements, > (both for clock rates and phase rate of change apart from overall > structure) it's hard to be specific. I will also mention I used > discrete and analog techniques (ECL for the logic) - this was in the > days before really fast VLSI (or even really fast LSI for that matter, > excepting ECL), but the same techniques could be used simply transposed > completely into the digital domain. > > Maybe I'll chew over it over the next couple of days, run up some code > over the weekend and post it (warning : I prefer Verilog ;) > > Maybe :) > > Cheers > > PeteSArticle: 106287
I got a "circuit", which is doing integer division with large values. I instantiated a MEGAWIZ-devider with currently 48bits / 16 Bits, which ist fed with some more bits (done be shifting) in order to obtain a result with a higher accuracy than 1 in one step without proceeding the remainder. E.g. I am shifting with 10 Bits and fill the rest with zero: input <= "0000" & Value (33 downto 0) & "0000000000" I recognize, that Quartus is obviously capable of synthesizing away to signals / paths in the devider which are not needed. Now, what is about the range of values ? In my design, the A / B have a certain relationship, so that the result can never exceed 18 bits, whereby the vector of the result (devider out) has of course 48 bits. Is it of an advantage if the range of values is restricted? Currently I am cutting away the first bits, which will always be zero. s there anything more, I can do, to keep the design small ?Article: 106288
I'm trying to construct a SOPC component of JOP [1]. As it did not work in the FPGA on the first try (of course) I would like to simulate it with ModelSim (Altera version). However, when I start ModelSim from Quartus I get following error: # ** Error: (vcom-11) Could not find C:\altera\Modeltech_ae\win32aloem/../altera/vhdl/altera.altera_europa_support_lib. # ** Error: D:/usr/cpu/jop/quartus/tmp/jop_system.vhd(24): (vcom-1195) Cannot find expanded name: 'altera.altera_europa_support_lib'. # ** Error: D:/usr/cpu/jop/quartus/tmp/jop_system.vhd(24): Unknown record element "altera_europa_support_lib". I found the VHDL file in the Quartus directory. Do I need to compile it (once ?) with ModelSim, or is there a PATH issue? Versions: Quartus 6.0sp1, ModelSim ALTERA 6.1d Thanks, Martin [1] http://www.jopdesign.com/Article: 106289
heinerlitz@gmx.de wrote: > HI, > > I am sorry I am running Mig 1.5 was a typo. > > Right now iam encountering two problems: > > If i post a sequence of reads to the read fifo, the first one always > fails than I have several succesful reads. I posted 256 writes and > sucessive reads and they were all succesfull besides the first one. > Strangely inl in a really long succesive write then read out sequence > (1k read ops) the first 100 are not succesfull and then I get 256 > succesful read outs and the again errors for the remaining ones. Often > the read out values are almost correct like only some 2-3 bits > different.. When the first or last element of a burst is missing, it could be a sign that the pipelining is off somewhere. For example, you expect data to arrive after 4 clocks, but it comes after 3 clocks and so you miss the first one. Often this is paired with an unexpected data value at the end. At least this is a repeatable problem. Sounds like another job for ChipScope. > > >>If these values never change, then you don't have the same problem that >>I did. > > But then again I hardcoded the observed (static) values and NOTHING > worked anymore. Idont know if I can trust chipscope. Whenever I find (rarely) ChipScope giving me impossible answers, I invariably discover that either I'm not looking where I thought I was or that my circuit doesn't work the was that I assumed it would. > > How did you decide to hardcode the values? Are the rising and falling > clk_count connected in some way like if one is reg3 teh other one is > also reg3? I hard coded the values because I notcied that they weren't always the same after calibration. As you stated before, this doesn't seem to be a problem that you have. --- Joe Samson Pixel VelocityArticle: 106290
Hi Evan, thanks for your response. The code was originally written for the Leonardo synthesiser, and at the time the synthesis attribute needed to be given as a string, but the simulation generic was a ulogic_vector. (We wrote our own simulation models for the primitives to support ulogic). Most of the INITs are static "2345" etc so to avoid possible errors between synthesis and simulation the 'init trick works quite well. until XST that is .... in this case RAM16X1D is a xilinx primitive, so I would have to put the "1234" in the generic as well I guess. a_core : if true generate >attribute INIT of ramd : label is "1234"; >begin > ramd : RAM16X1D > generic map ( > INIT => str2suv(ramd'INIT) <<<< here is the problem For XST I think (I will test this) the generic on it's own will give the correct synthesis result, but then I can't run it through Leonardo again. Cheers, Mike.Article: 106291
> > I thought the ngc2edif tool might come into it somewhere, but how > exactly do I end up with a VHDL file? > > Cheers, > > Robin Mentor tools such as Leonardo or Precision can take an EDIF and produce a VHDL file - it's not terribly readable, but you can simulate it. I am sure the other vendors can do the same trick. /MikeArticle: 106292
So, the secret seems to be solved. The problem is based on serial slave configuration routines. Via JTAG, the FPGA runs correctly, but same configuration stream on serial slave cannot. And I read many documentation PDFs, PPTs, HTML sites for the sollution. Now, I got a little success, now I'm passed the problem to microcontroller programmer group. About the problem: only one CCLK clock period sended to fpga after DONE pin rising to high, other documents tells this clock period must be three cycles after DONE rising high (XAPP098): one to IOs activate, one to GSR release and the last cycle to begin user operation. now I'm waiting for the programmers group response with a correct firmware of MCU. Thank you for the powerfull help! Best regards Jozsef Marc Randolph wrote: > Aurelian Lazarut wrote: > > I would check (at least) two things, > > 1. If the board finishes the configuration process gracefully, I mean > > DONE goes high, start-up clock need to be matched with your config type > > (jtagclk or cclk or userclk) mode pins are set correctly. > > But beware of in slave select-map mode, when DONE really means "not > quite done yet" or "you're almost done". By default, CCLK has to be > strobed several more times after DONE goes high. > > Have fun, > > MarcArticle: 106293
found one solution, adding -- pragmas to stop XST seeing the problem :)
attribute INIT of mux4_lut1 : label is "00CA";
begin
mux4_lut1: LUT4
--pragma translate_off
generic map (
lut => str2suv(mux4_lut1'INIT)
)
--pragma translate_on
port map (
I0 => DIN0(i),
Article: 106294Which parts? How long was delivery? What is the cost? What development/OEM boards are available?Article: 106295
burn.sir@gmail.com wrote: > Gurus just talk ... > No, they jump aroundArticle: 106296
Yes, Mikhail I know that. In fact I sucesfully implemented tcl script to generate fifo on the fly. But to properly create argument file (.arg) file for the purpose is a real "black magic" without a user manual (if it only exsisted). Right now I am on that mission to crate an arg file for fifo with asymetric ports. It is much easier to create a netlist and include it in /netlist directory. Damn Xilinx, how can they make life miserable. Cheers, Guru MM wrote: > Many of the Xilinx pcores, e.g. ll_temac use a TCL script to check if a > coregen generated netlist already exists and to generate one it if it > doesn't exist. > > /Mikhail > > > > "Guru" <ales.gorkic@email.si> wrote in message > news:1155207923.790368.106990@m73g2000cwd.googlegroups.com... > > Hi all, > > > > I am building EDK peripheral with FIFO Coregen 2.3 included. In ISE > > peripheral project everything is working fine (FIFO netlist is included > > and properly sinthesized and built), but in EDK flow every time i get > > an error during bulid: "unresolved FIFO - missing netlist or pin > > misspeling can cause this..." > > > > I have of course included in MPD: > > OPTION IMP_NETLIST = TRUE > > OPTION STYLE = MIX > > OPTION RUN_NGCBUILD = TRUE > > > > and in BDD file: > > Files > > async_fifo.edn > > async_fifo_fifo_generator_v2_3_fifo16_1.edn > > > > and in PAO FIFO wrapper: > > lib peripheral_v1_00_a async_fifo vhdl > > > > > > but the problem persists (and eating my nerves :( ). Files are not > > properly copied (included) to project implementation directory. I > > managed to resolve the problem by manually copying netlists to the imp > > directory, but that is not what I want. > > > > My methodology obviously doesn't work. Does anyone knows the proper > > procedure to fix this (or is maybe willing to give an example)? > > > > Cheers, > > > > Guru > >Article: 106297
> Tommy, as you said, if the initial construct is non synthesizable, > then how is a pin set to a default value using verilog? In any case, > isn't the memory location supposed to store the multiplication > result? > > Regards, > Santanu Some devices allow you to assign default/startup values to registers. It can be done for Altera parts through assignment editor. A common alternative (and i think generally accepted as better) approach is to have a reset signal, which triggers an "always" block. i.e. module somemodule(... rst, ..., outA ...) ... output [31:0] outA; reg [31:0] out_regA; ... always @(posedge rst) begin out_regA <= 32'h00000000; end ... ... end moduleArticle: 106298
> I found the VHDL file in the Quartus directory. Do I need to > compile it (once ?) with ModelSim, or is there a PATH issue? Compile it. KJArticle: 106299
In article <FsvCg.13358$rd1.2604@trnddc01>, Nevo <nevo_n@hotmail.com> wrote: >Just plug it into the wall. The PROM comes preloaded with demo code that >makes the blinkylights and countynumbers. (At least, the one I got last >week does...) > True, but what I was looking for was a VHDL example for displaying things on the various blinylights, etc. Someone else linked to some code at Xilinx that apparently does those things. Phil
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