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 John, johnblake2000@gmail.com wrote: > 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: > [snip] > 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. This sounds a lot like a problem I had last year - double check your ordering of the address lines out from the SDRAM controller - Xilinx numbers them backwards from the convention in memory device data sheets. See this thread: http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/8699cd7d6dc2a2b8/56f106a9f3f63641?lnk=gst&q=williams+ddr2&rnum=1#56f106a9f3f63641 Regards, JohnArticle: 123976
On Sep 8, 10:39 am, "johnblake2...@gmail.com" <johnblake2...@gmail.com> wrote: > I've been struggling for weeks to get sdram to work correctly on a > newly designed board. ... > -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. Your reasoning looks sound. It might help to look at the sdram data pins. You can copy opb_sdram (assuming that is what you are using) to you r local pcores directory and modify it with an extra port to output the sdram data. Then you can look at it with chipscope_ila. Alan NishiokaArticle: 123977
Hi. I have a question. I have a special y=f(x) function. It takes 32 bit at input and it have something at output. Function is unrolled, it computes result alsmost "immediately", and it doesn't contain any memory cells and flip-flops, it is what called "combinatorial". I need to fill a table of all possible x's and function results. If x is 32-bit, I just make 32-bit counter connected to the block which compute the result and collect results. As yet it all simple. But I feel that by rewiring bus between counter and f(x) block, I can reduce the number of gates changed its state at each counter's iteration, and vice versa. Thus to reduce power consumption. (I may have x in any order, my task is just to have all possible values of x at some moment). So, is there any tool that can take my f(x) in form of Verilog or VHDL and tell me what is the most optimal wiring scheme?Article: 123978
frankzhangee@gmail.com wrote: > 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. You've clicked on the 'continuous acquisition' button rather than the 'single acquisition' button... Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 123979
drop669@gmail.com wrote:
> Hi.
> I have a question.
> I have a special y=f(x) function. It takes 32 bit at input and it have
> something at output. Function is unrolled, it computes result alsmost
> "immediately", and it doesn't contain any memory cells and flip-flops,
> it is what called "combinatorial".
> I need to fill a table of all possible x's and function results. If x
> is 32-bit, I just make 32-bit counter connected to the block which
> compute the result and collect results.
> As yet it all simple.
> But I feel that by rewiring bus between counter and f(x) block, I can
> reduce the number of gates changed its state at each counter's
> iteration, and vice versa. Thus to reduce power consumption.
> (I may have x in any order, my task is just to have all possible
> values of x at some moment).
> So, is there any tool that can take my f(x) in form of Verilog or VHDL
> and tell me what is the most optimal wiring scheme?
For a dedicated once-only purpose, why are you concerned about power?
Are you a student who only has so many Joules allotted for use this
semester?
I know of no tools that could optimize this in a way that would make you
happy.
However, since changing one bit usually has fewer dynamic consequences
than changing many bits, consider a Gray code counter. The Gray code
counters only change one bit per increment. If you know which of your
32 bits typically uses less power when changing the logic through your
f(x), you could assign those to the LSbits of the Gray counter and leave
the "swich everything" x bits to the MSbits of the Gray counter.
If you don't know what a Gray counter is, there are many resources on
the web. A simple registered XOR of a binary counter would give you the
one bit change.
binCnt <= binCnt + 32'h1;
GrayCnt <= binCnt[31:0] ^ {1'b0,binCnt[31:1]};
Good luck.
Article: 123980> However, since changing one bit usually has fewer dynamic consequences > than changing many bits, consider a Gray code counter. The Gray code > counters only change one bit per increment. If you know which of your > 32 bits typically uses less power when changing the logic through your > f(x), you could assign those to the LSbits of the Gray counter and leave > the "swich everything" x bits to the MSbits of the Gray counter. Thanks, I know what Gray counter is. But the problem is, that on bus between counter and f(x) I can make increment in manner of Gray counter, but I never now that this property of Gray counter will reflect to each point of f(x) block. I mean that I'm not sure that Gray counter is simple solution.Article: 123981
I have a verilog design on Spartan 3 which needs to move to Cyclone II. The design has 7 128x1 bit asynchronous ROMs using ROM128X1 primitives (this is called distributed ROM?). Does Cyclone II have something similar? what is the primitive and initialisation syntax? If not will I have to use an lpm_rom megafunction and burn M4K blocks? The ROMs have common addressing so after some hassle rearranging the initialisation data I could use a single 128x7 bit ROM or after some hassle rearranging the design and initialisation data a 896x1 bit ROM. TIA --Article: 123982
drop669@gmail.com wrote: >>However, since changing one bit usually has fewer dynamic consequences >>than changing many bits, consider a Gray code counter. The Gray code >>counters only change one bit per increment. If you know which of your >>32 bits typically uses less power when changing the logic through your >>f(x), you could assign those to the LSbits of the Gray counter and leave >>the "swich everything" x bits to the MSbits of the Gray counter. Besides Binary, and Gray, we have also used Triangle counters (up/Down binary) where that made better table-mapping sense. > > Thanks, I know what Gray counter is. But the problem is, that on bus > between counter and f(x) I can make increment in manner of Gray > counter, but I never now that this property of Gray counter will > reflect to each point of f(x) block. I mean that I'm not sure that > Gray counter is simple solution. Since you presumably already have mapping software, to create your table, then you could modify that to do transistion calculations. So, you could easily do ALL counter candidates, and run both an edge count in your own SW, and then also the FPGA tools to given another power comparison on the candidate designs. -jgArticle: 123983
> So, you could easily do ALL counter candidates, and run > both an edge count in your own SW, and then also the FPGA tools to > given another power comparison on the candidate designs. If counter is 32-bit, then 32!=263130836933693530167218012160000000 This is a number of possible rewiring variants. I'm not feel myself as pioneer, so that's why I think that there must be some automated way...Article: 123984
nospam wrote: > I have a verilog design on Spartan 3 which needs to move to Cyclone II. > > The design has 7 128x1 bit asynchronous ROMs using ROM128X1 primitives > (this is called distributed ROM?). > > Does Cyclone II have something similar? what is the primitive and > initialisation syntax? > > If not will I have to use an lpm_rom megafunction and burn M4K blocks? The > ROMs have common addressing so after some hassle rearranging the > initialisation data I could use a single 128x7 bit ROM or after some hassle > rearranging the design and initialisation data a 896x1 bit ROM. > > TIA How about using generic verilog constructs instead? Using primitives is only going to be a source of headaches when used for no particular reason as FPGA architectures evolve and designs need to be ported across device families or vendors. Simply create an array of 7bits elements, initialize it to whatever your ROM's content has to be and use an index to access it. Pretty much any FPGA synthesis tool worth anything will be able to figure these out and do a satisfactory job in 99% of cases. I only use primitives for stuff that cannot be inferred. The other defendable reasons to use primitives is for timing-critical and space-critical logic/paths. That aside, I think they should be avoided.Article: 123985
drop669@gmail.com wrote: >>So, you could easily do ALL counter candidates, and run >>both an edge count in your own SW, and then also the FPGA tools to >>given another power comparison on the candidate designs. > > > If counter is 32-bit, then 32!=263130836933693530167218012160000000 > This is a number of possible rewiring variants. > I'm not feel myself as pioneer, so that's why I think that there must > be some automated way... That's a strange number - do you not have any idea what your f(x) might be ? Is this a real problem, or an academic one ? -jgArticle: 123986
On Sep 7, 6:38 am, kkoorndyk <kris.koorn...@gmail.com> wrote: > Although a little dated, I've found this 10 Commandments of Excellent > Design article useful. Also, "Fourteen Ways to Fool Your Synchronizer" is a reasonable paper http://www.ee.technion.ac.il/~ran/papers/Sync_Errors_Feb03.pdf -DougArticle: 123987
On Sep 7, 4:06 pm, eliben <eli...@gmail.com> wrote: > On Sep 7, 8:14 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > > > Paul Keinanen wrote: > > > (snip) > > > > If the OP required only something dedicated point to point > > > connectivity, why bother with the IP wrapper, just send raw Ethernet > > > frames with MAC addressing ? > > > You could, but sending UDP isn't that much harder. If you really want > > to simplify it, put the destination MAC address in as a constant > > 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. > > > The next complication is > > generating the CRC for UDP, but that is optional. The ethernet > > CRC has to be generated in either case. > > CRC generation in FPGAs is blazing fast, so I don't really see a > problem here. > > Eli Hi Eli, I am build a similar thing: a GLAN high-speed camera based on low-cost Avnet Virtex4 Mini-Module. I modified Xilinx GSRD2 to fit on this module. Sending pure ethernet frames you can achieve 730-850 MBit/s. The LL_TEMAC is DMA based peripheral with hardware checksum. If you need any other information or the complete desing do not hesitate to contact me. Chers, GuruArticle: 123988
drop669@gmail.com wrote: >> So, you could easily do ALL counter candidates, and run >> both an edge count in your own SW, and then also the FPGA tools to >> given another power comparison on the candidate designs. > > If counter is 32-bit, then 32!=263130836933693530167218012160000000 > This is a number of possible rewiring variants. > I'm not feel myself as pioneer, so that's why I think that there must > be some automated way... Your desire is too specific and never a concern in mainstream design so there simply is no automated way.Article: 123989
On Sep 10, 4:03 pm, John_H <newsgr...@johnhandwork.com> wrote: > drop...@gmail.com wrote: > >> So, you could easily do ALL counter candidates, and run > >> both an edge count in your own SW, and then also the FPGA tools to > >> given another power comparison on the candidate designs. > > > If counter is 32-bit, then 32!=263130836933693530167218012160000000 > > This is a number of possible rewiring variants. > > I'm not feel myself as pioneer, so that's why I think that there must > > be some automated way... > > Your desire is too specific and never a concern in mainstream design so > there simply is no automated way. Well... I'll try to simplify my desire. Is there any tool that can show me gates count switched if I preset previous state of inputs and next state?Article: 123990
On Sep 9, 12:39 am, John_H <newsgr...@johnhandwork.com> wrote:
> KJ wrote:
> > "John_H" <newsgr...@johnhandwork.com> wrote in message
> >news:13e07ln903ocg34@corp.supernews.com...
> >> <aclegg1...@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_H- Hide quoted text -
>
> - Show quoted text -
Hi,
Out of curiosity I decided to list the signals applicable to
one of the back-annotated registers, as shown below:
ps delta q d clrn prn clk d_ipd clrn_ipd prn_ipd
clk_ipd
0 +0 0 U U U U U U
U U
0 +1 X U 1 1 X U U
U U
0 +2 X U 1 1 X U 1
1 X
0 +7 X X 1 1 X U 1
1 X
0 +8 X X 1 1 X X 1
1 X
3900 +2 X X 1 1 0 X 1
1 X
3900 +3 X X 1 1 0 X 1
1 0
I had the idea to force all inputs except the d's and q's to an
inactive state and the output was given below (note clock force was
removed at approx 40000):
ps delta q d clrn prn clk d_ipd clrn_ipd prn_ipd
clk_ipd
0 +0 0 U 1 1 0 U 1
1 0
0 +7 0 X 1 1 0 U 1
1 0
0 +8 0 X 1 1 0 X 1
1 0
400000 +3 0 X 1 1 1 X 1
1 0
400000 +4 0 X 1 1 1 X 1
1 1
400400 +4 x X 1 1 1 X 1
1 1
The q still went to X on the rising edge of the clk_ipd, obviously due
to the d input being at x, but not sure why the D input remained at x?
Then I noticed that all the registers had their CLRN inputs connected
to the VCC net, I forced this signal low for 10ns and removed the
force. The design then sprang into life, I was curious to know if this
is legitimate?
I also still do not understand why all the registers Q outputs go to X
unless I hard code an async reset, which I can not do at present
(manager is happy with design as appears to work on the board,
although wants it back-annotated, the original designer has left) or
use the hack listed above?
Article: 123991Hi, I'm working on design with LVDS signals and when I'm trying to place LVDS inputs at dedicated pins I got : Error: Non-differential I/O pin addr[8] in pin location 86 and pad 103 too close to differential I/O pin clk_pll(n) in pin location 90 and pad 107 -- pins must be separated by a minimum of 4 pads And I don't know why ? How can it be too close ? Is any workaround for this ? (CYCLON II 2C5) AdamArticle: 123992
On Sep 7, 7:57 am, motty <mottobla...@yahoo.com> wrote: > The problem is in the testbench file that theMIGcreates. It only > instantiates and connects 1 memory IC. Thus from a module > perspective, there is a lot missing. I instantiated 3 more IC's to > get the thing working. > > Xilinx should explicitly state that info in the readme file. I didn't > pick up on it from that file or theMIGuser guide..but maybe I'm > dense. Hi Motty, I checked with a MIG specialist on this and this is what she said: "The readme in the sim directory does give some information on this. MIG 2.0 which is coming with IP Update #2 in October will provide testbenches and memory models specific to the option specified in MIG so this will no longer be an issue." Thanks DuthArticle: 123993
<aclegg1986@googlemail.com> wrote in message news:1189430931.168927.275430@22g2000hsm.googlegroups.com... <snip> > > Hi, > > Out of curiosity I decided to list the signals applicable to > one of the back-annotated registers, as shown below: > > ps delta q d clrn prn clk d_ipd clrn_ipd prn_ipd > clk_ipd > 0 +0 0 U U U U U U > U U > 0 +1 X U 1 1 X U U > U U > 0 +2 X U 1 1 X U 1 > 1 X > 0 +7 X X 1 1 X U 1 > 1 X > 0 +8 X X 1 1 X X 1 > 1 X > 3900 +2 X X 1 1 0 X 1 > 1 X > 3900 +3 X X 1 1 0 X 1 > 1 0 > > I had the idea to force all inputs except the d's and q's to an > inactive state and the output was given below (note clock force was > removed at approx 40000): > > ps delta q d clrn prn clk d_ipd clrn_ipd prn_ipd > clk_ipd > > 0 +0 0 U 1 1 0 U 1 > 1 0 > 0 +7 0 X 1 1 0 U 1 > 1 0 > 0 +8 0 X 1 1 0 X 1 > 1 0 > 400000 +3 0 X 1 1 1 X 1 > 1 0 > 400000 +4 0 X 1 1 1 X 1 > 1 1 > 400400 +4 x X 1 1 1 X 1 > 1 1 > > The q still went to X on the rising edge of the clk_ipd, obviously due > to the d input being at x, but not sure why the D input remained at x? > Then I noticed that all the registers had their CLRN inputs connected > to the VCC net, I forced this signal low for 10ns and removed the > force. The design then sprang into life, I was curious to know if this > is legitimate? > I also still do not understand why all the registers Q outputs go to X > unless I hard code an async reset, which I can not do at present > (manager is happy with design as appears to work on the board, > although wants it back-annotated, the original designer has left) or > use the hack listed above? The Xilinx simulation models have a GSR signal that can be included in simulation which globally resets all non-memory synchronous elements. The Altera simulation probably has a similar reset. For the Altera simulation folks here, what can be done to initialize the Altera part? If you're doing RTL simulation rather than post-placement back-annotated simulation, the situation is much simpler. In Verilog, use "initial" blocks to initialize all your register values. No forces required. Are you Verilog or VHDL? - John_HArticle: 123994
You never did answer the question: "John_H" <newsgroup@johnhandwork.com> wrote in message news:Ep0Fi.361$Z33.181@trndny08... > > For a dedicated once-only purpose, why are you concerned about power? Are > you a student who only has so many Joules allotted for use this semester?Article: 123995
Hello all,
I am trying to implement a network adapter that sends small packets to
and from FPGA boards using VHDL. I want to download this and test it
out, but I am getting the following synthesis error when I try to
generate the bit file in Xilinx:
Related source file is "usa/delvecch/project1/Packet_Gen.vhd"
ERROR:Xst:2108 - Logic for signal <packet_out> is controlled by a
clock but does not appear to be a valid sequential description
ERROR:Xst:1431 - Failed to synthesize unit <Packet_Gen>.
Here is my code for the packet generation module:
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;
entity Packet_Gen is
port( clkin: in std_logic;
reset: in std_logic;
load: in std_logic;
fwd: in std_logic;
dest_addr: in std_logic_vector (1 downto 0);
packet_fwd: in std_logic_vector (5 downto 0);
packet_out: out std_logic_vector (5 downto 0));
end Packet_Gen;
architecture behavioral of Packet_Gen is
signal load_prev: std_logic := '0';
begin
PG_proc: process (clkin, reset) is
begin
if (reset = '0') then
packet_out <= "000001";
elsif (clkin'event and clkin = '1') then
if (fwd = '0') then
if (load_prev = '0' and load = '1')
then
packet_out <= "100" &
dest_addr & '1';
else
packet_out <= "000001";
end if;
else
packet_out <= packet_fwd;
end if;
end if;
load_prev <= load;
end process PG_proc;
end behavioral;
To briefly describe the operation, if reset is 0 (active low), load
packet_out with an inactive packet ("000001"). For this design, a
packet is transmitted every rising edge of the clock cycle. If fwd is
0, then a packet is not being forwarded from another adapter, and a
new packet must be created. If a rising edge is detected on the load
signal, an active packet is created, otherwise an inactive packet is
created. If fwd is 1, simply forward the input packet (packet_fwd) to
the output (packet_out).
I am new to VHDL, so I'm not quite sure why I'm getting this error or
how I should go about fixing it. Any suggestions? I appreciate any
help that you may have for me. Thanks.
Article: 123996Hi, I would like to know what is the name of Altera latest and most advanced chip serial that is competable in technology with Xilinx Vertex V in terms of system strucute(LUT6..., not 65nm). Thank you. WengArticle: 123997
Hi, I want to know what is called carry chain structure in FPGA is called in IC? Thank you. WengArticle: 123998
ray.delvecchio@gmail.com wrote:
> I am new to VHDL, so I'm not quite sure why I'm getting this error or
> how I should go about fixing it.
Maybe load_prev <= load; should be inside the clocked IF.
In general, to fix problems like this requires a vhdl simulator.
You would get more responses by posting to comp.lang.vhdl
-- Mike Treseler
Article: 123999
On Sep 10, 4:31 pm, "John_H" <newsgr...@johnhandwork.com> wrote:
> <aclegg1...@googlemail.com> wrote in message
>
> news:1189430931.168927.275430@22g2000hsm.googlegroups.com...
> <snip>
>
>
>
>
>
>
>
> > Hi,
>
> > Out of curiosity I decided to list the signals applicable to
> > one of the back-annotated registers, as shown below:
>
> > ps delta q d clrn prn clk d_ipd clrn_ipd prn_ipd
> > clk_ipd
> > 0 +0 0 U U U U U U
> > U U
> > 0 +1 X U 1 1 X U U
> > U U
> > 0 +2 X U 1 1 X U 1
> > 1 X
> > 0 +7 X X 1 1 X U 1
> > 1 X
> > 0 +8 X X 1 1 X X 1
> > 1 X
> > 3900 +2 X X 1 1 0 X 1
> > 1 X
> > 3900 +3 X X 1 1 0 X 1
> > 1 0
>
> > I had the idea to force all inputs except the d's and q's to an
> > inactive state and the output was given below (note clock force was
> > removed at approx 40000):
>
> > ps delta q d clrn prn clk d_ipd clrn_ipd prn_ipd
> > clk_ipd
>
> > 0 +0 0 U 1 1 0 U 1
> > 1 0
> > 0 +7 0 X 1 1 0 U 1
> > 1 0
> > 0 +8 0 X 1 1 0 X 1
> > 1 0
> > 400000 +3 0 X 1 1 1 X 1
> > 1 0
> > 400000 +4 0 X 1 1 1 X 1
> > 1 1
> > 400400 +4 x X 1 1 1 X 1
> > 1 1
>
> > The q still went to X on the rising edge of the clk_ipd, obviously due
> > to the d input being at x, but not sure why the D input remained at x?
> > Then I noticed that all the registers had their CLRN inputs connected
> > to the VCC net, I forced this signal low for 10ns and removed the
> > force. The design then sprang into life, I was curious to know if this
> > is legitimate?
> > I also still do not understand why all the registers Q outputs go to X
> > unless I hard code an async reset, which I can not do at present
> > (manager is happy with design as appears to work on the board,
> > although wants it back-annotated, the original designer has left) or
> > use the hack listed above?
>
> The Xilinx simulation models have a GSR signal that can be included in
> simulation which globally resets all non-memory synchronous elements. The
> Altera simulation probably has a similar reset.
>
> For the Altera simulation folks here, what can be done to initialize the
> Altera part?
>
> If you're doing RTL simulation rather than post-placement back-annotated
> simulation, the situation is much simpler. In Verilog, use "initial" blocks
> to initialize all your register values. No forces required.
>
> Are you Verilog or VHDL?
>
> - John_H- Hide quoted text -
>
> - Show quoted text -
Hi,
I am using a VHDL Altera generated netlist for back anno +
VHDL for RTL, at present in RTL I am setting the vhdl signals to the
required values in the signal declaration area.
Thanks
Andy
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