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
The PPC has a 64bit cycle counter built-in. If all you want is count cycles, it's probably best to just use it. Best regards, MarcArticle: 138101
On 6 =AAubat, 04:36, n...@rblack01.plus.com wrote: > Hi, > > Say I have a register described by a clocked process: > > signal test_int : integer; > signal event1 : std_logic; > signal event2 : std_logic; > signal event3 : std_logic; > > process(clk) begin > =A0 =A0 =A0 =A0 if(clk'event and clk=3D'1') then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if(event1 =3D '1') then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 test_int <=3D 1; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if(event2 =3D '1') then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 test_int <=3D 2; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if(event3 =3D '1') then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 test_int <=3D 3; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 =A0 end if; > end process; > > If event1, event2 and event3 are all high when the clock edge occurs, > is test_int guaranteed to be set to 3 due to this being the last > assignment in the process? =A0 > > I am using Quartus II targeting a Cyclone device. =A0There are no errors > or warnings given, I just want to make sure the design is not relying > on undefined behaviour. > > Thanks > > R. if all the signals are high at the same time "last if" executes. Becasue all the signal assignments in the process are sequential. In order to be "more sure" try the syntax "elsif". --enesArticle: 138102
On Feb 6, 3:37 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Thu, 5 Feb 2009 21:58:31 -0800 (PST), rickman wrote: > > [of the Ken Chapman UART design that jleslie48 is using] > > >Wow! I know it is possible and will potentially give you the optimum > >size design, but I have never actually seen a unit that was 100% > >instantiated. Technically this is VHDL. But for all practical > >purposes, this is a schematic expressed in text. > > Yes, I was pretty staggered too. It makes heavy use of SRL16s > to do the various shifters. It's an amazing piece of bravura > optimization, and for something totally re-usable like a UART > it's probably a rather good idea to have such a thing handy. > > >> the reset to the UART being handled? I don't think it makes a > >> difference, I never send one. > > >I see that the UART has no reset. The FIFO however, *does* have a > >reset which is the signal reset_buffer driven by your signal > >UART_RESET_BUFFER. So that needs to be asserted for a while before > >the UART is used. Otherwise the FIFO counters may not be in the right > >state. > > I think jleslie48's design does indeed assert that > FIFO reset appropriately for a few clock cycles at startup. > > >Actually, I think I have lost the thread of what the problem is. Is > >the simulation working 100% and the real chip is *not* working? If > >so, looking at the simulation won't tell you a lot. > > It might be worth re-stating my data point from yesterday: > I created a simple message generator design myself, using > the same UART macros that jleslie48 uses, and it works > just fine both in simulation and in real hardware (Spartan-3 > starter kit, 50MHz system clock; the timing report says it's > all good for at least 110MHz). So I really don't think it > will do the OP any good to try to understand the very tricksy > coding of the UARTs. He can use them out-of-the-box with > confidence. > > I didn't get an answer to my question yesterday about whether > the OP's 16.7MHz divided clock is correctly distributed on > an internal clock net - i.e., has the Xilinx software > correctly recognized it to be a clock. Careless use of > a divided or gated clock is a likely culprit for mismatch > between simulation and hardware. The OP should consider > clocking absolutely everything from his 100MHz system clock, > and increasing the baud rate divider to the appropriate value. > I'm not saying it would make any difference, but at least > it would remove one source of uncertainty (oops, sorry, > a "known unknown"). > -- > 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.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. Ok, I took a good look at the code; this is brilliant. You have built a formatted output handler. I can't wait to try this out. "I didn't get an answer to my question yesterday about whether the OP's 16.7MHz divided clock is correctly distributed on an internal clock net - i.e., has the Xilinx software correctly recognized it to be a clock." I took some measurements with both the simulator and the oscilliscope on the ASCII code coming out and the clock time is exactly what was expected: I just realized you can even see me checking that in this screencap (11): http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap11_missingfirstletter.png anyway I'll be building a new project today and analyzing your formatted output generator. Thanks again, Jonathan LeslieArticle: 138103
Jon Beniston wrote: > ASIC library. However, I suspect your biggest problem is the > instantiation of the DCM and SERDES blocks as you will not have these > in your ASIC library either. What is your plan for those? If you use > different IP for these, you will not need the cells listed above. I think the biggest problem is that if you don't have a clue what you are doing the end result will not be very succesful. And with current NRE prices there is no room for trial and error. FPGA<->ASIC transitions are not push button things. Usually the whole clocking has to be redone, special IP has to be recoded or bought, testability has to be taken into consideration etc. For example depending on the serdes speed it might be doable with normal IO on ASIC. Or full custom analog+digital design is required which of course can be bought but is not in any way cheap. With FPGA many blocks are there as a default, with asic the ip availability is very vendor/fab dependent. --KimArticle: 138104
Hi, There is no problem when I configure my FPGA from BPI with an unencypted bitstream, in fact I could reprogram it by pulsing program button.Unfortunately it is not the case for the encrypted one. why ? Have I commited a mistake? Or it's due to the speed of the decryptor ? Thank youArticle: 138105
On Fri, 6 Feb 2009 05:29:44 -0800 (PST), jleslie48 wrote: >> I didn't get an answer to my question yesterday about whether >> the OP's 16.7MHz divided clock is correctly distributed on >> an internal clock net - i.e., has the Xilinx software >> correctly recognized it to be a clock." > I took some measurements with both the simulator and > the oscilliscope on the ASCII code coming out and the > clock time is exactly what was expected: There's no doubt that your clock divider correctly generates a 16.67MHz clock (100MHz/6). My concern is that you have not used an internal DCM (clock manager block) to do it. Clock signals have a very special status, and very special needs, in an FPGA. The device has extensive dedicated resources carefully designed to get a clock signal to all its registers at closely the same time, with negligible skew between them. If you create a derived clock and, for some reason, it gets distributed round the chip on general-purpose routing resources rather than on the dedicated clock tree, then some very bad things can happen. And those bad things probably won't appear in simulation, unless you do a full back-annotated timing sim. I would *guess* that ISE has correctly identified your 16.67MHz signal as a clock, and has correctly put it on to the dedicated clock tree. But it is a nasty thing that you have done there, and I would prefer to be rid of it. 100MHz is not outrageously fast, so you could clock EVERYTHING from the 100MHz clock and merely arrange for the UART baud rate enable to happen one clock cycle in 54, instead of one in 9 as you have at present. -- 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: 138106
Thanks for the input, points taken. I'll be giving the Wishbone bus a go. It's always good to support open source standards. MannyArticle: 138107
On Feb 5, 8:10 am, Svenn Are Bjerkem <svenn.bjer...@googlemail.com> wrote: > Hi, > > I am in the middle of writing VHDL to read from one block-ram and > write the read data into another block-ram, both same data witdth and > address width. Device is a Spartan-3A. Now, block ram data is > presented at the output of the RAM to read on the next clock cycle, > and this leads to a shift in address data in the RAM to write. Address > 0 becomes 0 (reset value on data bus) Address 1 get data from Address > 0 of source RAM, address 2 get data from address 1 on source RAM etc. > From what I have read about this, the data is available a few > nanoseconds after the edge, so one suggestion was to use the falling > edge to read data. The process that I wrote to do this doesn't allow > me to do this so I just inserted an extra register on the write > address to align the address with data for the write operation. There > are probably several snags to watch for doing things this way, and I > thought maybe I should ask how other Xilinx users solve this "problem" > > -- > Svenn Svenn, you can also use First word fall through (FWFT) feature of Xilinx FIFO Generator. This way you get zero latency. Cheers, AlesArticle: 138108
On Feb 5, 2:10=A0am, Svenn Are Bjerkem <svenn.bjer...@googlemail.com> wrote: > Hi, > > I am in the middle of writing VHDL to read from one block-ram and > write the read data into another block-ram, both same data witdth and > address width. Device is a Spartan-3A. Now, block ram data is > presented at the output of the RAM to read on the next clock cycle, > and this leads to a shift in address data in the RAM to write. Address > 0 becomes 0 (reset value on data bus) Address 1 get data from Address > 0 of source RAM, address 2 get data from address 1 on source RAM etc. > From what I have read about this, the data is available a few > nanoseconds after the edge, so one suggestion was to use the falling > edge to read data. The process that I wrote to do this doesn't allow > me to do this so I just inserted an extra register on the write > address to align the address with data for the write operation. There > are probably several snags to watch for doing things this way, and I > thought maybe I should ask how other Xilinx users solve this "problem" > > -- > Svenn Assuming you don't have other problems with the latency, your pipelined approach should work. What gets tricky is reading and writing data to the same RAM, for example using Block RAM to store histogram data. You can't do read/mod/write in the same cycle because of the read delay (two ports doesn't help this either). Two ports allows you to update the memory on every clock cycle, but the pipeline delay means that you need to have the updated data for the RAM before you read out the old value. So you need to delay the write, which means you run into trouble if you need to update the same cell on successive clocks. In the case of the histogram, you can keep the most recently written data in a register and use it instead of the RAM readback when you need to update the same cell. Regards, GaborArticle: 138109
news@rblack01.plus.com wrote:
> If event1, event2 and event3 are all high when the clock edge occurs,
> is test_int guaranteed to be set to 3 due to this being the last
> assignment in the process?
Yes, at the next clock edge.
If event 3 is active, then
the value of 1 and 2 don't matter.
-- Mike
Article: 138110I can't see those options in ISE 10.1i any more. How can I do the map PAR in guide mode now? Anyone knows how to set this mode please ?Article: 138111
On Feb 5, 1:53=A0pm, Lorenz Kolb <lorenz.k...@uni-ulm.de> wrote: > GrIsH wrote: > > I am using spartan-II board..and in my project, i need number of > > signals of different frequencies..So i want to divide 50Mz clock of > > Spartan-II board to get the clocks of required frequencies...... > > So anyone suggest me on How to divide the clock frequency??......... > > any help will be greatly appreciated............................. > > Either use DCMs or use counters generating enable-signals for the faster > clocks to act as slower clocks. > > Avoid using counters to generate your own clocks. > > Regards, > > Lorenz Spartan II won't have DCM's, only DLL's. The first question is what frequencies do you need and are they simple integer divisions from your 50 MHz? If so, use simple counters with a single decoded state to provide a clock enable for the slower logic. The flip-flops in the Spartan II all have clock enables, so there is no need to use multiple clocks (there are only 4 global clock nets in that part IIRC) if your frequencies are simple divisions from a single master clock. Regards, GaborArticle: 138112
Marlboro wrote: > I can't see those options in ISE 10.1i any more. > > How can I do the map PAR in guide mode now? Anyone knows how to set > this mode please ? Did you read the manual? The bit about guided mapping? HTH., Syms.Article: 138113
so quiz question:
Xilinx OPB_LCD
known good hardware
known working C code:
(everything from xilinx s3a-sk ref design)
lcd_init(XPAR_CHAR_LCD_BASEADDR);
lcd_clear(XPAR_CHAR_LCD_BASEADDR);
lcd_print(XPAR_CHAR_LCD_BASEADDR, 1, "Hello!");
the LCD doesnt display anything, why?
answer:
need DELAY
lcd_init(XPAR_CHAR_LCD_BASEADDR);
lcd_clear(XPAR_CHAR_LCD_BASEADDR);
// stupid delay
for (i=0; i<2000;i++) {
xil_printf("!");
}
lcd_print(XPAR_CHAR_LCD_BASEADDR, 1, "Hello!");
now the hello is printed on the LCD :)
Antti
Article: 138114On Feb 6, 9:20 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > I would *guess* that ISE has correctly identified your > 16.67MHz signal as a clock, and has correctly put it > on to the dedicated clock tree. But it is a nasty > thing that you have done there, and I would prefer > to be rid of it. 100MHz is not outrageously fast, > so you could clock EVERYTHING from the 100MHz clock > and merely arrange for the UART baud rate enable to > happen one clock cycle in 54, instead of one in 9 > as you have at present. > -- > 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.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. 16.67Mhz is generated by 1/6th of the 100MHZ. 1/9th of that is exactly that, 1/6*/19 == 1/54 of the 1000Mhz. If this machine can't get that right, I'm gonna be in a whole world of hurt. More importantly, I ran JB_LOKI_TOP. and it works like a charm: http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap16_jbworking01.png and I love the formatted output model. Now the rest of the program is disabled, right now, but that's ok, I'm very interested in this output model. the generic map gives me the parameter concept for allowing different messages to be go out, and I want to explore controlling when this entity fires, for triggered calls to Uart messages. I definitely owe you a dinner for this one. sincerely JonArticle: 138115
On Fri, 06 Feb 2009 12:36:49 +0000, news@rblack01.plus.com wrote:
>Say I have a register described by a clocked process:
>
>signal test_int : integer;
>signal event1 : std_logic;
>signal event2 : std_logic;
>signal event3 : std_logic;
>
>process(clk) begin
> if(clk'event and clk='1') then
> if(event1 = '1') then
> test_int <= 1;
> end if;
> if(event2 = '1') then
> test_int <= 2;
> end if;
> if(event3 = '1') then
> test_int <= 3;
> end if;
> end if;
>end process;
>
>If event1, event2 and event3 are all high when the clock edge occurs,
>is test_int guaranteed to be set to 3 due to this being the last
>assignment in the process?
As Mike and Enes have already confirmed, the answer is "yes".
Just to enlarge on this a little: When you make
a <= signal assignment in VHDL, you are scheduling -
planning - an update to the signal for some time in
the future. A simple assignment
s <= e;
evaluates expression "e" immediately, and then schedules
an assignment of that value on to signal "s" for a time
one delta cycle into the future. From an RTL/design
perspective, you can think of that delta cycle as being
"just after the clock edge".
s <= e after 5 ns;
evaluates "e" immediately, but schedules the update of
"s" for 5 ns into the future. Of course you can't
meaningfully do this for a synthesizable design,
because synthesis does not know how to make time delays
reliably, so it will be treated exactly the same as
the zero-delay assignment for synthesis (and you may
get a warning message).
But what happens when you make more than one assignment
to the same signal, as in your example? The answer is
quite complicated to describe, but has simple and
intuitive effects:
When you execute the signal assignment, it schedules an
update to the signal at some future time T, which can
be anything greater than or equal to (NOW + 1 delta).
This new scheduled update affects any existing scheduled
updates as follows:
1) Any existing scheduled updates at times >= T are
cancelled. This is the behaviour that your code
depends on.
2) Working backwards from time T towards NOW, VHDL
inspects each scheduled update to "s". If it is
to EXACTLY THE SAME VALUE as your new update,
the existing earlier scheduled update is preserved.
But as soon as VHDL encounters an update to a
different value, it cancels that and all earlier
updates.
The second behaviour has the interesting effect that
repeated attempts to bring a signal to a certain value
after a time delay will indeed succeed. Consider this:
for i in 1 to 10 loop
s <= K after 10 ns; -- K is the same every time.
wait for 5 ns;
end loop;
Suppose you start this loop at time 0; when will "s"
change its value to K? Answer: at time 10 ns. The
second assignment, executed at time 5 ns and scheduled
for 15 ns, does NOT cancel the 10 ns schedule because
it's to the same value.
If you don't want a new assignment to affect existing
already-scheduled updates, you can use transport delay:
s <= transport e after 10 ns;
This form of assignment creates the new schedule without
affecting previous scheduled assignments; in other words,
it obeys my rule (1) but it ignores rule (2).
Of course, most of this stuff makes sense only for
simulation, not for synthesis. But it justifies
doing multiple assignments to the same signal within
a synthesizable process; it is completely certain
that only the last-executed assignment will take effect.
--
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: 138116ssirowy@gmail.com wrote: > > The problem comes when I migrate this functionality to a PowerPC > system, and now my custom counter sits on the PLB bus. This time, with > the same code, the counter reads ~70-75 cycles for each successive > read, basically a full order of magnitude difference, and thus my > results are getting completely screwed up. Just take the counter that's built into the PPC. It's built in. For an example on how to use that counter you can e.g. have a look at the code from one of last year's Xcell articles. Measuring acceleration using PPC's APU and custom instructions. Here's the link: http://www.missinglinkelectronics.com/support/ Regards, LorenzArticle: 138117
On Fri, 6 Feb 2009 02:20:29 -0800 (PST), mjunaidelahi@gmail.com wrote: >I have got Verilog code for a design that has been implemented on >Virtex-4. My target is take this design to an ASIC implementation. The >issues that I am having right now are related to porting an FPGA based >design to an ASIC. When I read this design into Cadence synthesis >tools, I get few unresolved references for IDELAYCTRL, ODDR, BUFG, >BUFR, BUFIO, BUFGMUX_VIRTEX4. These modules are placed in the design >as follows: > > > >IDELAYCTRL - connected to DCM > >ODDR - connected to DCM > >BUFG - connected to DCM > >BUFR - connected to SERDES > >BUFIO - connected to SERDES > >BUFGMUX_VIRTEX4 - connected to DCM > > > >It seems that these modules as xilinx specific and are automatically >instantiated in the verilog code when DCM and SERDES components were >configured using xilinx tools. Can you please kindly guide on what >should I do about these componets as there is no code for these >modules in my code directory? Has anyone else experienced this sort of >issue before when moving an FPGA-based implementation to an ASIC? As other posters have mentioned some of these cells are specific to DCM and SERDES blocks. Specifiically IDELAYCTRL & ODDR will not be needed when you get ASIC IP. The other cells are clock buffer cells and need to be removed so that ASIC CTS can implement them itself. The BUFGMUX is a standard glitchless clock mux which also needs to be implemented in behavioral RTL, used with CTS and timed properly. You need to re-architect your top level for an FPGA to ASIC port and it seems it would be better if you get some real help. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 138118
On Fri, 6 Feb 2009 09:39:09 -0800 (PST), jleslie48 wrote:
> 16.67Mhz is generated by 1/6th of the 100MHZ. 1/9th of that is
> exactly that, 1/6*/19 == 1/54 of the 1000Mhz. If this machine
> can't get that right, I'm gonna be in a whole world of hurt.
No, no!!!! I'm not disputing either your or the counter's
arithmetic. I'm making a crucial point about HARDWARE.
The 16.67MHz clock is used as the clock input to many,
many registers. If some of those registers see an
active edge of that clock significantly before or
after others, then there is a BIIIIIG problem of
hold time violation. That is the problem that the
on-chip clock tree is designed to solve, and the problem
that you MUST avoid by ensuring that your clocks find
their way on to those clock trees correctly. However,
it sounds as though the tools are doing their due
diligence for you and all is well.
>More importantly, I ran JB_LOKI_TOP. and it works like a charm:
Nice to know that we can help kick-start your efforts.
> and I love the formatted output model.
Hah! I think "formatted" is stretching a point. But
it certainly makes it easier to change the messages.
However.... I note that you have invented an integer constant
FLF to hold a line separator; you don't need to do that;
VHDL has predefined CHARACTER constants for all those things,
and they can be included in the message strings thanks to
the tua() function that type-converts a string into an
array of bytes:
the_program =>
op_DELAY & 255 &
op_MESSAGE & tua("Just one line" & CR & LF) & EOM &
op_MESSAGE & tua("2nd line" & CR & LF & "3rd line") & EOM
.....
> I want to explore controlling when this entity fires,
> for triggered calls to Uart messages.
PLEASE DO NOT think about "firing" or "calling" an entity.
An entity instance just sits there, doing its thing, for
the entire life of the universe. It "fires" on every
clock edge, whether you like it or not. You must find a
way to modify its operation under control of some other
signal(s) that come in through its input ports.
Suppose you decided that you want to use an input on the
serial Rx line to trigger something. You could imagine
adding a "wait for a certain character" opcode to add
to the program. Just add a couple of new states to the
state machine, and a new command constant, and add ports
to access the receive UART...
So, that thought made me smile, so I've updated the two
files at the same URL as before. Here's the "program" now:
, the_program =>
-- Long startup delay
op_DELAY & 200 &
-- Welcome message starts at address 2.
op_MESSAGE & tua(CR&LF&"Hello"&CR&LF) & EOM &
-- Wait for a "+" from the keyboard...
op_WAIT_FOR_CHAR & tua("+") &
-- and then print another message
op_MESSAGE & tua("abcdefghijklmnopqrstuvwxyz"&CR&LF) & EOM &
-- Wait for a "-" from the keyboard
op_WAIT_FOR_CHAR & tua("-") &
-- and then go back to the beginning! - no delay this time.
op_GOTO & 2
The state machine is getting a tad messy now, and this is a
good sign that we're starting to do things that are better
done in software using a little embedded processor core
such as Picoblaze. I haven't really made any effort to
clean up the state machine code; it could be much better
than it currently is.
Enjoy.
--
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: 138119I've been using a heavily-hacked-together version of xc3sprog with the Xilinx Parallel cable IV for a while now under linux. However, more and more machines lack parallel ports, and I'm looking for an alternative. The Xilinx Platform Cable (2) USB was an option, except that setup is a bit of a pain, and there don't appear to be any Free tools for programming devices with it. I like to leave JTAG adaptors around at customers' sites such that I can try a bit of remote debugging before I end up on site, but this is getting increasingly difficult without the parallel ports. I also wouldn't want to be installing the full ISE suite on customers machines if I could avoid it. I've not had any success using USB-to- parallel-port converters, either. Given these, what do people recommend for programming their Xilinx devices? I'd like the following: 1. Works close-to-out-of-the-box under linux 2. Cheap (<$250) 3. Non-horrible software that works under 32- and 64-bit OSes, ideally with source 4. the ability to get at the USERn registers from the FPGA, either from the command line or an API. 5. ships out-of-the-box with the xilinx 2x7 2mm header for JTAG. Has anyone seen any options that might get me close to this? Thanks, ...EricArticle: 138120
Hi, all. Note: I mistakenly cross-posted this to comp.lang.verilog; I meant to post it here. I was wondering if anyone had any recommendations for an HDL simulator. I'm considering Mentor ModelSim, Synopsys VCS, and Cadence IUS (NC-Sim). If you had to chose between the 3 for FPGA work, which one would you chose? It seems that there's a huge variance in the pricing I'm getting from the respective EDA vendors and am wondering if the more expensive simulators are worth it. Also, I'm mostly a Verilog programmer. Does anyone see a big downside to getting the ModelSim Verilog-only version? Background information: I'm aware of http://groups.google.com/group/comp.lang.verilog/browse_thread/thread/c12a37ded957f3c/ " which commercial HDL-Simulator for FPGA?", so I was going to go with ModelSim. However, I'm scratching my head wondering why VCS and IUS are so much more expensive. I'd like to know what I'm giving up before I make the plunge. I've been using Icarus Verilog for simulation up to this point. I'm also looking at Verilator. However, I've just been given some outside IP that is compiled (for ModelSim) or encrypted (for VCS or IUS). As a result, I will need a commercial simulator. In addition, the IP provides a board-functional model (BFM). My understanding is that I need a commercial simulator to do this level of simulation.Article: 138121
On Feb 6, 2:16 pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Fri, 6 Feb 2009 09:39:09 -0800 (PST), jleslie48 wrote:
> > 16.67Mhz is generated by 1/6th of the 100MHZ. 1/9th of that is
> > exactly that, 1/6*/19 == 1/54 of the 1000Mhz. If this machine
> > can't get that right, I'm gonna be in a whole world of hurt.
>
> No, no!!!! I'm not disputing either your or the counter's
> arithmetic. I'm making a crucial point about HARDWARE.
> The 16.67MHz clock is used as the clock input to many,
> many registers. If some of those registers see an
> active edge of that clock significantly before or
> after others, then there is a BIIIIIG problem of
> hold time violation. That is the problem that the
> on-chip clock tree is designed to solve, and the problem
> that you MUST avoid by ensuring that your clocks find
> their way on to those clock trees correctly. However,
> it sounds as though the tools are doing their due
> diligence for you and all is well.
>
> >More importantly, I ran JB_LOKI_TOP. and it works like a charm:
>
> Nice to know that we can help kick-start your efforts.
>
> > and I love the formatted output model.
>
> Hah! I think "formatted" is stretching a point. But
> it certainly makes it easier to change the messages.
>
> However.... I note that you have invented an integer constant
> FLF to hold a line separator; you don't need to do that;
> VHDL has predefined CHARACTER constants for all those things,
> and they can be included in the message strings thanks to
> the tua() function that type-converts a string into an
> array of bytes:
>
> the_program =>
> op_DELAY & 255 &
> op_MESSAGE & tua("Just one line" & CR & LF) & EOM &
> op_MESSAGE & tua("2nd line" & CR & LF & "3rd line") & EOM
> .....
>
> > I want to explore controlling when this entity fires,
> > for triggered calls to Uart messages.
>
> PLEASE DO NOT think about "firing" or "calling" an entity.
> An entity instance just sits there, doing its thing, for
> the entire life of the universe. It "fires" on every
> clock edge, whether you like it or not. You must find a
> way to modify its operation under control of some other
> signal(s) that come in through its input ports.
>
> Suppose you decided that you want to use an input on the
> serial Rx line to trigger something. You could imagine
> adding a "wait for a certain character" opcode to add
> to the program. Just add a couple of new states to the
> state machine, and a new command constant, and add ports
> to access the receive UART...
>
> So, that thought made me smile, so I've updated the two
> files at the same URL as before. Here's the "program" now:
>
> , the_program =>
> -- Long startup delay
> op_DELAY & 200 &
> -- Welcome message starts at address 2.
> op_MESSAGE & tua(CR&LF&"Hello"&CR&LF) & EOM &
> -- Wait for a "+" from the keyboard...
> op_WAIT_FOR_CHAR & tua("+") &
> -- and then print another message
> op_MESSAGE & tua("abcdefghijklmnopqrstuvwxyz"&CR&LF) & EOM &
> -- Wait for a "-" from the keyboard
> op_WAIT_FOR_CHAR & tua("-") &
> -- and then go back to the beginning! - no delay this time.
> op_GOTO & 2
>
> The state machine is getting a tad messy now, and this is a
> good sign that we're starting to do things that are better
> done in software using a little embedded processor core
> such as Picoblaze. I haven't really made any effort to
> clean up the state machine code; it could be much better
> than it currently is.
>
> Enjoy.
> --
> 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.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com
>
> The contents of this message may contain personal views which
> are not the views of Doulos Ltd., unless specifically stated.
whoa!!!! hold on there! now things are getting interesting!
first,
"However.... I note that you have invented an integer constant
FLF to hold a line separator; you don't need to do that;
VHDL has predefined CHARACTER constants for ..."
thanks for the tip. I tried those first but got an error mesage.
I thought I could use those as
op_MESSAGE & tua("Hello") &CR&LF & EOM &
but that is syntactically incorrect.
thanks for the correct syntax:
op_MESSAGE & tua("Hello"&CR&LF) & EOM &
you've got a whole mess of computing power built into the
entity now, and while I'd love to offset this into a picoblaze
C programming environment, I won't have that at my disposal so
your state machine built out of VHDL is starting to look mighty pretty
to me.
first off, I just took a quick dander at the new code,
and its set for the 50Mhz clock yes?
In my 100Mhz world the line:
IF ( BAUD_COUNT = 26 ) THEN
in the P4 process:
P4: PROCESS ( SYSTEM_CLOCK )
BEGIN
IF ( SYSTEM_CLOCK = '1' AND SYSTEM_CLOCK'EVENT ) THEN
IF ( BAUD_COUNT = 26 ) THEN
BAUD_COUNT <= 0;
UART_EN_16_X_BAUD <= '1';
ELSE
BAUD_COUNT <= BAUD_COUNT + 1 ;
UART_EN_16_X_BAUD <= '0';
END IF;
END IF;
END PROCESS P4;
should be 54 yes?
and this:
TRANSMIT_UART : entity work.uart_tx
port map
(
data_in => TX_DATA_IN,
write_buffer => TX_WRITE_BUFFER_STB,
reset_buffer => UART_RESET_BUFFER,
en_16_x_baud => UART_EN_16_x_BAUD,
serial_out => RS232_TX_DATA,
buffer_full => TX_BUFFER_FULL,
buffer_half_full => TX_BUFFER_HALF_FULL,
clk => SYSTEM_CLOCK
);
isn't the clk here supposed to be:
the 1/6th clock?
clk => CLK_16_6MHZ
I think I'm missing something on understanding how these clocks work.
"PLEASE DO NOT think about "firing" or "calling" an entity.
An entity instance just sits there, doing its thing, for
the entire life of the universe. It "fires" on every
clock edge, whether you like it or not. "
Ok, I'm missing something or maybe I'm just not useing the
right words.
In your ver 1.0, the entity data_gen in JB_Loki_Top
generated 1 and only one message output message:
A
abcdefghijkinsertherelmnopqrstuvwxyz12345678pqr
and entity instantiation was in the concurrent logic
portion of the loki_top architecture behavorial.
now it finished with an op_halt, so I'm guessing that
in the details of data gen I'm going to see that HALT
render data_gen silent, until reboot time, or I imagine
if I give that
reset => '0' a real signal to set the output message to
resend.
Again I think I'm mucking up the language of describing what
is the chain of events, but the fact is data_gen put ~something
out once and only once, and I'm quite sure their is a way I can have
that ~something come out again bases on a change of ~some signal.
That is what I meant by ` "firing" or "calling" an entity. ` I
messing up
on the language, but I do realize that the entity is in a state of
continuous
activity, and it is a matter of controlling the boolean signals to a
state of
true and false to make it do one thing (put out a message) or another
(just
sit there)
I'm going to take a good hard look at data_gen, specifically the
change from
simple, one shot firing to your new looper with conditional waits.
I know your going to hate this, but I like that second element of the
generic map
of data_gen being "the_program". It has established some linear
events that are
a lot more familiar to me.
Sincerely,
Jonathan Leslie
Article: 138122thank you guys for the information akshay >Andreas Ehliar <ehliar-nospam@isy.liu.se> writes: > >>On 2009-01-22, akshay <akshayvreddy@gmail.com> wrote: >>> Hi, >>> i am trying to implement a small SIMD machine on and fpga vertex-2 chip.To >>> test this unit i have to load a user defined RAM with data. i have an >>> assembler that generates hex code. I have to get this hex code into the RAM >>> so that i can test the data flow. > >>Finally, the most elegant solution is probably to write a small bootloader >>in ROM which you can use to download your program via a serial port or so. > >Or arrange to execute the program from (initialized) ROM instead of RAM. >-- > mac the naïf >Article: 138123
news@rblack01.plus.com wrote: > Say I have a register described by a clocked process: (snip) > If event1, event2 and event3 are all high when the clock edge occurs, > is test_int guaranteed to be set to 3 due to this being the last > assignment in the process? As others have noted, the answer is yes. The result is more complicated logic than would otherwise be needed. If you don't need that complication, then you are getting bigger and slower logic than you would otherwise have. Not so bad at three levels, but it gets worse as it gets bigger. (This is a priority encoder.) If you need many levels, you can nest priority encoders, reducing the number of levels of logic needed to get the result. (A little similar to carry lookahead logic.) As far as I know, the synthesis tools won't generate a nested priority encoder for you. > process(clk) begin > if(clk'event and clk='1') then > if(event1 = '1') then > test_int <= 1; > end if; > if(event2 = '1') then > test_int <= 2; > end if; > if(event3 = '1') then > test_int <= 3; > end if; > end if; > end process; -- glenArticle: 138124
On Fri, 6 Feb 2009 12:56:38 -0800 (PST), jleslie48 wrote:
>whoa!!!! hold on there! now things are getting interesting!
Yup. You've given me an excuse to waste a lot of time
playing around with my little Spartan-3 kit :-)
>thanks for the correct syntax:
>op_MESSAGE & tua("Hello"&CR&LF) & EOM &
There's no reason in principle why the generic
should not be a string; but, as I pointed out, there
are some <cough> features of ISE that mean it is
safer to use an array of 8-bit integers instead.
So I wrote the tua() conversion function to cast
a string to an array of 8-bit ints. CR and LF
are character, not integer constants, so they must
form part of the STRING (=array of character) that
is converted by tua().
>you've got a whole mess of computing power built into the
>entity now,
Not anywhere near enough, yet. I do feel, though, that
I got a lot more bang per line of code than you did :-)
>and while I'd love to offset this into a picoblaze
>C programming environment, I won't have that at my disposal
Whyever not? What's the objection to having a soft core
inside the FPGA to do the slow procedural/sequential stuff?
No-one is forcing you into TELLING your client it's there...
and the great joy of an FPGA is that you can also add as
much custom high-speed hardware as you need, alongside
the CPU that you need to do the messy-but-slow stuff.
> your state machine built out of VHDL is starting
> to look mighty pretty to me.
It was deliberately set up as a tutorial teaser - I hope
you don't find that patronizing, it certainly wasn't
intended to be so. Unfortunately it does not scale
particularly well; each time I add new functionality
to it, its performance degrades measurably. The first
version (just DELAY and MESSAGE operations) gave me
up to 120MHz clock speed in my Spartan-3. Adding the
GOTO and WAIT_FOR_CHAR operations degraded the maximum
possible speed to about 105MHz. Not a problem so far,
but clearly some real design effort will be needed if
you want to add any more serious capabilities.
>first off, I just took a quick dander at the new code,
>and its set for the 50Mhz clock yes?
yup, sorry, I sent you the wrong version. Well spotted!
>In my 100Mhz world the line:
> IF ( BAUD_COUNT = 26 ) THEN
>in the P4 process:
>
>P4: PROCESS ( SYSTEM_CLOCK )
>BEGIN
> IF ( SYSTEM_CLOCK = '1' AND SYSTEM_CLOCK'EVENT ) THEN
> IF ( BAUD_COUNT = 26 ) THEN
> BAUD_COUNT <= 0;
> UART_EN_16_X_BAUD <= '1';
> ELSE
[...]
>should be 54 yes?
Yes. (53, I think, because the count is zero-based.)
Note I used an INTEGER signal for the count. You may need to
tweak its declaration to make its range wide enough.
Better still, declare some constants:
constant clock_freq_Hz : positive := 100_000_000;
constant desired_baud_rate: positive := 115_200;
-- let VHDL do the work of computing the divisor!
constant baud_rate_divisor: positive :=
clock_freq_Hz / (desired_baud_rate * 16);
and then make the declaration and the code match automatically:
signal baud_count: natural range 0 to baud_rate_divisor-1;
...
if baud_count = baud_rate_divisor-1 then
baud_count <= 0;
UART_EN_16_X_BAUD <= '1';
else
baud_count <= baud_count + 1;
...
>and this:
>TRANSMIT_UART : entity work.uart_tx
> port map
[...]
> clk => SYSTEM_CLOCK
>isn't the clk here supposed to be:
>the 1/6th clock?
No. That was absolutely intentional. I wanted the whole
thing clocked from my single system clock. I didn't see
the point in your /6 clock, and I still don't. Set the
Baud-rate divisor to 53 (so you get 100MHz/54) and let
that do the work.
>I think I'm missing something on understanding how these clocks work.
Possibly. If you want something to operate once every N system
clocks, it is usually better NOT to use a divided-by-N clock
directly, but rather to use a divider similar to your baud
rate prescaler and then to write a process like this...
if rising_edge(system_clock) then
if (enable_once_per_N_system_clocks = '1') then
do whatever you want;
end if;
end if;
Your hardware-oriented co-worker will probably be able to
help explain why this is so. Please trust me on this.
>"PLEASE DO NOT think about "firing" or "calling" an entity.
> An entity instance just sits there, doing its thing, for
> the entire life of the universe. It "fires" on every
> clock edge, whether you like it or not. "
>
>Ok, I'm missing something or maybe I'm just not useing the
>right words.
>In your ver 1.0, the entity data_gen in JB_Loki_Top
>generated 1 and only one message output message:
>
>A
>abcdefghijkinsertherelmnopqrstuvwxyz12345678pqr
Because its "program" caused it to do so, and then
had a HALT operation that put it into a stuck state
so that it made no further progress. It still continues
to operate on every clock edge - it's just that it is
in an internal state that happens to make no progress;
a jump-to-self loop, in software terms.
>now it finished with an op_halt, so I'm guessing that
>in the details of data gen I'm going to see that HALT
>render data_gen silent, until reboot time, or I imagine
>if I give that
>reset => '0' a real signal to set the output message to
>resend.
Exactly so.
>Again I think I'm mucking up the language of describing what
>is the chain of events, but the fact is data_gen put ~something
>out once and only once, and I'm quite sure their is a way I can have
>that ~something come out again bases on a change of ~some signal.
See the new version. It works. Try it (with the baud divisor
appropriately patched to 53 for your higher clock rate).
>I know your going to hate this, but I like that second element of the
>generic map
>of data_gen being "the_program". It has established some linear
>events that are a lot more familiar to me.
That was (more or less) intentional. Think about it for a moment:
Your hardware is an invariant lump of silicon. It must, inevitably,
do exactly the same thing on each and every clock cycle. But by
keeping some state information, and by adjusting the logic's
outputs and its future state as a function of that state, we
can make the design progress through a series of states and
therefore APPEAR to have sequential behaviour. What I gave
you was an impossibly primitive programmable machine;
"the_program" is precisely its program, and you can even find,
explicitly in the design, a PROGRAM COUNTER that steps its way
through that program. It is not a huge leap of imagination
from there to a proper general-purpose programmable CPU.
--
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.
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