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
On Oct 29, 10:45=A0pm, Brian Drummond <brian_drumm...@btconnect.com> wrote: > > Seconded. If you need to read files created by other tools (e.g. a spread= sheet, > or a binary file like a .bmp) this is a reasonable way to do it, and more > flexible than the above approach. However ISE Simulator has some > not-well-documented obstacles(*) to reading binary files, which is more > straightforward in Modelsim. > > (*) As of ISE10: > a) it is opposite-endian to Modelsim's treatment of the same file. > b) ISIM writes an undocumented header before the file contents, and expec= ts to > see that header on any file it reads. You can convert a 3rd party file to= /from > ISIM using head, tail and cat to extract/insert the header (on Linux, or = the > Windows equivalent commands) but it's a bother. > c) =A0Xilinx have declined to document this header. However there is a Ch= ange > Request to fix these issues; I have no idea if/when it will happen. > > - Brian Thanks Brian, good to know. Thankfully I can probably get away with not using binary files for input. I am on Linux and we don't have funding at the moment for stuff like Modelsim licenses, so I'm pretty much bound to the ISE simulator for now. I know Modelsim is smoother and nicer, but they were not nice enough to make Modelsim XE for Linux :( I'll just make the big array of constants, and rewrite the file whenever I need to make changes to it.Article: 143851
On Oct 29, 6:47=A0am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Thu, 29 Oct 2009 06:22:33 -0500, "zss" <zarit...@yahoo.com> wrote: > >Hi, I'm designing using ROM and hex file.I'm new at using this. > >I've created this .hex file for the ROM and everytime I close the quartu= s > >window and open the hex file again to edit it, it says > > >"cant open file -- file contains ni memory cell values"..?? > > >what I did wrong?help > > You may need to build a shrubbery. > > - Brian Perhaps this will help: <http://wiki.answers.com/Q/How_do_you_cut_down_a_tree_with_a_herring>Article: 143852
Have you checked that your DONE signal has gone high thereby releasing the chip out of config and into operation. Use the JTAG to do a status read if you don't have access to the signal. John Adair Enterpoint Ltd. - Home of Merrick1. The ASIC Prototype Platform. On 29 Oct, 10:39, crescent <hanpei...@gmail.com> wrote: > Hi all, > I am now using an Atmel AT45DB321D SPI flash booting xc5vsx50t-ff1136 > and there is something wrong. First, the FPGA can be programmed > successfully, and the flash also can be programmed successfully both > directly & indirectly via iMPACT. But the FPGA just can't boot from > the flash. I checked the timing diagram of the signals: PROG_B, > INIT_B, M[2:0], FS[2:0], FCS_B, CCLK, MOSI, DIN, the MOSI did not > function right compared to the timing diagram in XAPP951 page8 (M[2:0] > =001,FS[2:0]=111). Pin MOSI clocks out 001100000.... after FCS_B goes > low and it should be 000010110... > I have no idea what's wrong and what should I do to fix this. So any > help would be thankfull!Article: 143853
On Oct 30, 1:57=A0am, John Adair <g...@enterpoint.co.uk> wrote: > Have you checked that your DONE signal has gone high thereby releasing > the chip out of config and into operation. Use the JTAG to do a status > read if you don't have access to the signal. > > John Adair > Enterpoint Ltd. - Home of Merrick1. The ASIC Prototype Platform. > - Show quoted text - John, Thank you for your reply. The signal DONE on my board drives a LED through a buffer. After FPGA successfully configured, the LED should light which is not seen when programming from flash. That's to say the FPGA is under configuration all the time.Article: 143854
In a two-process state machine with many outputs, I would like to have a few output signals whose values would be updated and latched on certain states, and left as they are during all other states. Is it correct that this can be accomplished by simply not assigning these signals with default values, and only including assignments for them during the states where I would like them latched? Is this sound coding practice? Thanks, TSMArticle: 143855
On 30 Okt., 07:23, TSMGrizzly <sbatt...@yahoo.co.jp> wrote: > In a two-process state machine with many outputs, I would like to have > a few output signals whose values would be updated and latched on > certain states, and left as they are during all other states. > > Is it correct that this can be accomplished by simply not assigning > these signals with default values, and only including assignments for > them during the states where I would like them latched? Is this sound > coding practice? > > Thanks, > > TSM Hi, don't say "latched" here, with FPGAs we all want signals to be registered. ;-) And so, if your outputs are set in a registered process you can set them once and they keep that value as long as they are unchanged. But it's quite difficult do achieve with a standard two process FSM, where branches and outputs are handled in a combinatorical process. Ugly. In the past I favoured three process FSMs, but now I'm doing it in one process, where the state is stored in a variable (and the state type defined inside the process). Have a nice synthesis EilertArticle: 143856
<snip> > >I'll just make the big array of constants, and rewrite the file >whenever I need to make changes to it. > If your ROM is *really* big (> 1M locations) you may run into simulator difficulties if you define the contents as an array of std_logic_vector. Defining it as an array of integer is most memory-efficient, but you have to convert it to signed/unsigned and cast to std_logic_vector to drive the port. An array of bit_vector is 2nd best. --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 143857
On Oct 30, 2:23=A0am, TSMGrizzly <sbatt...@yahoo.co.jp> wrote: > In a two-process state machine with many outputs, I would like to have > a few output signals whose values would be updated and latched on > certain states, and left as they are during all other states. > > Is it correct that this can be accomplished by simply not assigning > these signals with default values, and only including assignments for > them during the states where I would like them latched? No. Think for a minute about it. You've got some output that is coming out of a flip flop. If you don't want it to change values then you make the default assignment to assign that output to the value currently in the output of the flop. > Is this sound coding practice? > The unsound practice is using an unclocked process which then implies that it is unsound to use a two process model. Processes with a sensitivity list that consist of more than just 'clock' are prone to creating design problems that are just not possible when written as a single clocked process [1]. Despite what textbooks would have you believe, state machines do not need to be coded as two processes. KJ [1] The problems with an unclocked process are: - Must insure that there is an assignment to every signal on every path through the process or a latch will be created which is a design problem that will need to then be fixed...after having to debug to find the problem. Typically this is accomplished by assigning default values at the begining of the process - Must insure that the sensitivity list is complete or the synthesized result will not match the code as written and interpreted by the simulator. - The default assignments are extra code that is not needed if written as a single process instead....it's your time.Article: 143858
Did you buffer the drive to the LED. If not this a common issue for DONE not making the correct logic level. Double check with the JTAG status to be sure. John Adair Enterpoint Ltd. On 30 Oct, 01:29, crescent <hanpei...@gmail.com> wrote: > On Oct 30, 1:57=A0am, John Adair <g...@enterpoint.co.uk> wrote: > > > Have you checked that your DONE signal has gone high thereby releasing > > the chip out of config and into operation. Use the JTAG to do a status > > read if you don't have access to the signal. > > > John Adair > > Enterpoint Ltd. - Home of Merrick1. The ASIC Prototype Platform. > > - Show quoted text - > > John, > Thank you for your reply. The signal DONE on my board drives a LED > through a > buffer. After FPGA successfully configured, the LED should light which > is not seen > when programming from flash. That's to say the FPGA is under > configuration all the > time.Article: 143859
On Oct 30, 11:10=A0am, "RCIngham" <robert.ing...@gmail.com> wrote:
> <snip>
> If your ROM is *really* big (> 1M locations) you may run into simulator
> difficulties if you define the contents as an array of std_logic_vector.
> Defining it as an array of integer is most memory-efficient, but you have
> to convert it to signed/unsigned and cast to std_logic_vector to drive th=
e
> port.
Danger, Will Robinson!
I note that your ROM table is going to contain 32-bit data. Please do
not forget that a VHDL "integer" value does not, repeat NOT,
correspond to a 32-bit two's complement integer! The "standard"
package, last time I checked, contained the immortal line:
type INTEGER is range -2147483647 to 2147483647;
-2147483648, or 2^-31 or 0x80000000, is not, repeat NOT, a valid
integer in VHDL! If there is a possibility that your ROM will contain
this most-negative value then you must check whether your simulator
actually allows it. It probably won't. Of course, if you were hoping
for 32-bit unsigned values in your ROM then that won't fit in an
integer either, for the same reason.
To be honest, a big array of std_logic_vector won't hurt *that* much:
subtype my_rom_data is std_logic_vector(31 downto 0);
type my_rom_type is array(0 to 65535) of my_rom_data;
But I recommend you define it as a constant or a variable, and never
as a signal:
signal x : my_rom_type :=3D (...); -- Noooo!
...because that will really slow everything down.
Cheers,
-Ben-
Article: 143860On Oct 30, 7:16=A0am, KJ <kkjenni...@sbcglobal.net> wrote: > On Oct 30, 2:23=A0am, TSMGrizzly <sbatt...@yahoo.co.jp> wrote: > > > In a two-process state machine with many outputs, I would like to have > > a few output signals whose values would be updated and latched on > > certain states, and left as they are during all other states. > > > Is it correct that this can be accomplished by simply not assigning > > these signals with default values, and only including assignments for > > them during the states where I would like them latched? > > No. =A0Think for a minute about it. =A0You've got some output that is > coming out of a flip flop. =A0If you don't want it to change values then > you make the default assignment to assign that output to the value > currently in the output of the flop. > > > Is this sound coding practice? > > The unsound practice is using an unclocked process which then implies > that it is unsound to use a two process model. =A0Processes with a > sensitivity list that consist of more than just 'clock' are prone to > creating design problems that are just not possible when written as a > single clocked process [1]. > > Despite what textbooks would have you believe, state machines do not > need to be coded as two processes. > > KJ > > [1] The problems with an unclocked process are: > - Must insure that there is an assignment to every signal on every > path through the process or a latch will be created which is a design > problem that will need to then be fixed...after having to debug to > find the problem. =A0Typically this is accomplished by assigning default > values at the begining of the process > - Must insure that the sensitivity list is complete or the synthesized > result will not match the code as written and interpreted by the > simulator. > - The default assignments are extra code that is not needed if written > as a single process instead....it's your time. Well, in the unclocked process you could make default assigns that are not to a constant but rather to the current output of the flip-flop in the clocked process. Then drop into the case statement. This is similar to what you get for "free" in the single-clocked-process FSM. What you lose in the clocked-only FSM is the ability to assign outputs based on the current state in the same process. I don't think there's anything inherently wrong with the two process approach as long as you understand what you're making. In the one-clock FSM process you'd often end up with outputs assigned in another process that depend on the state variable in order to accomplish the same end. I don't see how that's in any way better than the two-process FSM. Just my 2 cents, GaborArticle: 143861
You can also initialize a constant, variable, or signal with a function call that returns the value to be used for initialization. So if you have a simple enough algorithm for the contents to code in vhdl, that might be a simpler way yet. Oh, and use a constant if this is really a rom, rather than a signal, for less overhead and better performance. If you can use an integer (range constraints withstanding), it will be smaller and more efficient. The VHDL LRM requires AT LEAST the range -2147483647 to 2147483647 to be implemented for integer, but many (most?) implementations handle the entire 32 bit two's complement range. Check your simulator/synthesis tool's standard package implementation, because there is no "standard" standard package definition with regard to this. And if they don't implement the full 32 bit signed range, request an enhancement for them to do so. AndyArticle: 143862
On Oct 30, 7:38=A0am, John Adair <g...@enterpoint.co.uk> wrote: > Did you buffer the drive to the LED. If not this a common issue for > DONE not making the correct logic level. Double check with the JTAG > status to be sure. > > John Adair > Enterpoint Ltd. > > On 30 Oct, 01:29, crescent <hanpei...@gmail.com> wrote: > > > On Oct 30, 1:57=A0am, John Adair <g...@enterpoint.co.uk> wrote: > > > > Have you checked that your DONE signal has gone high thereby releasin= g > > > the chip out of config and into operation. Use the JTAG to do a statu= s > > > read if you don't have access to the signal. > > > > John Adair > > > Enterpoint Ltd. - Home of Merrick1. The ASIC Prototype Platform. > > > - Show quoted text - > > > John, > > Thank you for your reply. The signal DONE on my board drives a LED > > through a > > buffer. After FPGA successfully configured, the LED should light which > > is not seen > > when programming from flash. That's to say the FPGA is under > > configuration all the > > time. > > Other things to check: 1) Atmel Dataflash has a slightly different command set than most SPI flash parts. Be sure you have the right command for continuous array read. 2) If you think it's a startup issue rather than loading, you can enable the "internal Done pipe" in the bitgen options. Regards, GaborArticle: 143863
Gabor wrote: > In the one-clock > FSM process you'd often end up with outputs assigned in > another process that depend on the state variable in order > to accomplish the same end. I don't see how that's in any > way better than the two-process FSM. I would add any logic that depends on that state variable to the same process. > Just my 2 cents, Me too. -- Mike TreselerArticle: 143864
On Oct 30, 9:25=A0am, Gabor <ga...@alacron.com> wrote: > On Oct 30, 7:16=A0am, KJ <kkjenni...@sbcglobal.net> wrote: > > > On Oct 30, 2:23=A0am, TSMGrizzly <sbatt...@yahoo.co.jp> wrote: > > > > In a two-process state machine with many outputs, I would like to hav= e > > > a few output signals whose values would be updated and latched on > > > certain states, and left as they are during all other states. > > > > Is it correct that this can be accomplished by simply not assigning > > > these signals with default values, and only including assignments for > > > them during the states where I would like them latched? > > > No. =A0Think for a minute about it. =A0You've got some output that is > > coming out of a flip flop. =A0If you don't want it to change values the= n > > you make the default assignment to assign that output to the value > > currently in the output of the flop. > > > > Is this sound coding practice? > > > The unsound practice is using an unclocked process which then implies > > that it is unsound to use a two process model. =A0Processes with a > > sensitivity list that consist of more than just 'clock' are prone to > > creating design problems that are just not possible when written as a > > single clocked process [1]. > > > Despite what textbooks would have you believe, state machines do not > > need to be coded as two processes. > > > KJ > > > [1] The problems with an unclocked process are: > > - Must insure that there is an assignment to every signal on every > > path through the process or a latch will be created which is a design > > problem that will need to then be fixed...after having to debug to > > find the problem. =A0Typically this is accomplished by assigning defaul= t > > values at the begining of the process > > - Must insure that the sensitivity list is complete or the synthesized > > result will not match the code as written and interpreted by the > > simulator. > > - The default assignments are extra code that is not needed if written > > as a single process instead....it's your time. > > Well, in the unclocked process you could make default assigns > that are not to a constant but rather to the current output > of the flip-flop in the clocked process. That's what I said...so I guess we agree. > What you lose in the > clocked-only FSM is the ability to assign outputs based on > the current state in the same process. Unclocked outputs that are a function of current state can be handled with concurrent assignments. Treseler and Andy prefer to use variables and keep it all within the same process. Unclocked outputs that are a function of the next state are best handled with variables within the process. Handling them with concurrent assignments causes one to duplicate logic. In any case, there is nothing lost by having only one clocked process rather than two. > =A0I don't think there's > anything inherently wrong with the two process approach as > long as you understand what you're making. What is wrong with the two process approach is summed up in note [1] in my previous post. Yes, you can work around it, but doing so requires manual eyeball verification to insure the potholes have been missed. Personally, I prefer a road with no potholes. >=A0In the one-clock > FSM process you'd often end up with outputs assigned in > another process that depend on the state variable in order > to accomplish the same end. =A0 One can use signals in/out of the clocked process to avoid references to the state variable from outside the process if such references go against your grain. Again, the Treseler approach using variables avoids use of the state variable from outside the process...however this is just a technicality since his approach is to make the entire architecture one large process. The references to the state variable could be scattered all over that one large process, but technically there are no references to the state variable from outside the process. The distinctions only a nit-picker would love. > I don't see how that's in any > way better than the two-process FSM. > As I said in the first post, the two-process approach inherently has an unclocked process. The problems with an unclocked process are defined in note [1] in that same first post. Kevin JenningsArticle: 143865
On Oct 30, 8:25=A0am, Gabor <ga...@alacron.com> wrote:
> What you lose in the
> clocked-only FSM is the ability to assign outputs based on
> the current state in the same process. =A0I don't think there's
> anything inherently wrong with the two process approach as
> long as you understand what you're making. =A0In the one-clock
> FSM process you'd often end up with outputs assigned in
> another process that depend on the state variable in order
> to accomplish the same end. =A0I don't see how that's in any
> way better than the two-process FSM.
If at all possible, I rearrange states and/or output assignments
between them to avoid comibinatorial outputs, period.
If necessary, you CAN create combinatorial outputs from the state
registers in a single, clocked process, if you use a variable for the
state:
process (clk) is -- reset omitted for brevity
variable state : state_type;
begin
if rising_edge(clk) then
case state is
when ... =3D>
state :=3D ... ;
end case;
end if;
-- combinatorial logic after state regs:
output <=3D some_function_of(state, other_variables);
end process;
One other reason not to use combinatorial processes: simulators
optimize process overhead by merging processes with the same
sensitivity list. And since most combinatorial processes will have
unique sensitivity lists, they cannot be merged.
The use of variables is more efficient to simulate, and keeping one
process minimizes use of signals. Variables also hide the state
definitions from outside the process, making future maintenance of
them easier (less impact on other parts of the design if they could
not use your state variable in the first place).
If your synthesis tool does not accept signal assignments after the
clocked if-then-end-if, call the vendor and tell them that (at least)
Synplify and Quartus do.
Andy
Article: 143866Andy wrote: > If at all possible, I rearrange states and/or output assignments > between them to avoid combinatorial outputs, period. I agree. I like clean, synchronous interfaces between processes. > One other reason not to use combinatorial processes: simulators > optimize process overhead by merging processes with the same > sensitivity list. And since most combinatorial processes will have > unique sensitivity lists, they cannot be merged. And if I don't limit myself to one variable per process, my code is already in this merged format and easier to trace in modelsim. -- Mike TreselerArticle: 143867
KJ wrote: > Unclocked outputs that are a function of the next state are best > handled with variables within the process. Handling them with > concurrent assignments causes one to duplicate logic. A good point. In a clocked process, a variable ID represents the D side of some register. A port or signal ID represents the Q of some register. -- Mike TreselerArticle: 143868
On Oct 30, 11:09=A0am, Mike Treseler <mtrese...@gmail.com> wrote: > And if I don't limit myself to one > variable per process, my code is > already in this merged format and > easier to trace in modelsim. Simulators can merge processes with the same sensitivity list even accross hierarchy. If you wanted a little more privacy in a large single process, you could use procedures with local variables to create islands of locality within one process. You could still have "global" (within the process) variables by declaring those before the procedures in the process' declarative region. To expand upon the timer/fsm example I posted a couple of weeks ago, you could have a timer procedure and an fsm procedure within a process, with local and "global" variables as desired. E.g. If the timer/timeout variables were declared before both procedures, then they could be read and manipulated by both, but if the state variable was declared within the FSM process, only FSM could read/manipulate the state. I have seen some of your examples illustrate the use of procedures in template processes, but I don't remember any specific to scope control. AndyArticle: 143869
Andy wrote:
> To expand upon the timer/fsm example I posted a couple of weeks ago,
> you could have a timer procedure and an fsm procedure within a
> process, with local and "global" variables as desired. E.g. If the
> timer/timeout variables were declared before both procedures, then
> they could be read and manipulated by both, but if the state variable
> was declared within the FSM process, only FSM could read/manipulate
> the state.
I hear what you're saying.
If I had to put unrelated registers in the same entity,
I would do it like that.
I prefer to keep related registers together
and port map the wired interfaces to keep
the signal directions explicit.
> I have seen some of your examples illustrate the use of procedures in
> template processes, but I don't remember any specific to scope
> control.
I use port maps for scope control.
-- Mike Treseler
Article: 143870Why not, Just use Hyperterminal in the capture mode to record everything coming in on the RS232 port from the uart? Then use a text editor, perl script, or whatever to extract the information you want (if it needs filtering). I am presuming the text file resides on the same computer the RS232 is connected to, so this just makes more sense that what you seem to be doing. AustinArticle: 143871
Jon, In the RTL there is not much you can do except add the signals to the port list and bring them on up the hierarchy. Synthesis tools don't support hierarchical references to nets. To do so they would have to flatten the design hierarchy and it is not always wise to do that. I usually just make a bus of all the signals in the child modules and then route that up. If you use Xilinx's ChipScope insertion tool, then this can do the work for you. The downside is that that tool is terrible. In fact all the ChipScope tools are abysmal to use. I do everything by hand and then only use the ChipScope analyzer tool. I even name the signals by hand because the Xilinx tools are so bad. I wish they would at least use a sane XML input format and document that so we could just write scripts to feed the design information in. Even better would be to publish the JTAG commands and let someone suck up the information and stick it in a VCD file that could be read by your favorite waveform viewer. -Pete On Oct 28, 6:36=A0am, "maxascent" <maxasc...@yahoo.co.uk> wrote: > I have a design with some level of hierarchy and I want to connect a > chipscope ILA core to the bottom level. > > For example say I have 3 modules A, B and C with a signal temp in C. > Module A is the top level with B inside A and C inside B. > I would of thought that I could just do the following > > chipscope_ila U_ila( > =A0 =A0.CLK =A0 =A0 (clk), > =A0 =A0.CONTROL (control), > =A0 =A0.TRIG0 =A0 (A.B.C.temp)); > > The ila is in the top level and I want to monitor temp. > When I try and synthesize it with Synplify the program just errors. > Can anyone tell me what I am ddoing wrong? > > Thanks > > Jon =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > This message was sent using the comp.arch.fpga web interface onhttp://www= .FPGARelated.comArticle: 143872
On Fri, 30 Oct 2009 06:50:28 -0700 (PDT), Andy <jonesandy@comcast.net> wrote: >You can also initialize a constant, variable, or signal with a >function call that returns the value to be used for initialization. So >if you have a simple enough algorithm for the contents to code in >vhdl, that might be a simpler way yet. This is good, and any simulator will initialise the ROM fast. If it's junt for the testbench this is a really good idea. It is also synthesisable, and XST will handle it correctly ... BUT (you just knew there was a BUT coming) for a reasonably large ROM, or a complex function (e.g. function calls nested 4 levels deep) XST will take an unbelievably long time to synthesise it. There's an N^2 algorithm in there somewhere; if it takes 15 minutes for a 1000 element array, it'll take an hour for 2000 elements, 4 hours for 4000, etc... This is an unbelievably weak area of XST's performance, and every simulator I've tried proves this poor performance is completely unnecessary. >If you can use an integer (range constraints withstanding), it will be >smaller and more efficient. The VHDL LRM requires AT LEAST the range >-2147483647 to 2147483647 to be implemented for integer, but many >(most?) implementations handle the entire 32 bit two's complement >range. Modelsim handles -2^32, ISE Simulator gives a clear error message. - BrianArticle: 143873
On Fri, 30 Oct 2009 23:14:44 +0000, Brian Drummond wrote: >for a reasonably large ROM, or a complex function (e.g. function calls nested 4 >levels deep) XST will take an unbelievably long time to synthesise it. There's >an N^2 algorithm in there somewhere; if it takes 15 minutes for a 1000 element >array, it'll take an hour for 2000 elements, 4 hours for 4000, etc... Sounds as though XST is re-invoking the entire function to compute the value of each individual bit (or word?) of the ROM. Given the way synthesis tends to focus on each bit individually, that might be not too surprising. Yuck. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 143874
On Oct 30, 3:06=A0pm, sandbender <p...@coho.org> wrote: > Jon, > > In the RTL there is not much you can do except add the signals to the > port list and bring them on up the hierarchy. Synthesis tools don't > support hierarchical references to nets. To do so they would have to > flatten the design hierarchy and it is not always wise to do that. > > I usually just make a bus of all the signals in the child modules and > then route that up. If you use Xilinx's ChipScope insertion tool, then > this can do the work for you. The downside is that that tool is > terrible. In fact all the ChipScope tools are abysmal to use. I do > everything by hand and then only use the ChipScope analyzer tool. I > even name the signals by hand because the Xilinx tools are so bad. I > wish they would at least use a sane XML input format and document that > so we could just write scripts to feed the design information in. Even > better would be to publish the JTAG commands and let someone suck up > the information and stick it in a VCD file that could be read by your > favorite waveform viewer. > > -Pete > > On Oct 28, 6:36=A0am, "maxascent" <maxasc...@yahoo.co.uk> wrote: > > > > > I have a design with some level of hierarchy and I want to connect a > > chipscope ILA core to the bottom level. > > > For example say I have 3 modules A, B and C with a signal temp in C. > > Module A is the top level with B inside A and C inside B. > > I would of thought that I could just do the following > > > chipscope_ila U_ila( > > =A0 =A0.CLK =A0 =A0 (clk), > > =A0 =A0.CONTROL (control), > > =A0 =A0.TRIG0 =A0 (A.B.C.temp)); > > > The ila is in the top level and I want to monitor temp. > > When I try and synthesize it with Synplify the program just errors. > > Can anyone tell me what I am ddoing wrong? > > > Thanks > > > Jon =A0 =A0 =A0 =A0 > > > --------------------------------------- =A0 =A0 =A0 =A0 > > This message was sent using the comp.arch.fpga web interface onhttp://w= ww.FPGARelated.com- Hide quoted text - > > - Show quoted text - It is not necessary to insert the ICON and ILA cores in your original HDL. You can use the ChipScope Inserter to do this on your synthesized design. http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/chipscope_p= ro_sw_cores_11_1_ug029.pdf Ed McGettigan -- Xilinx Inc.
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