Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 138100

Article: 138100
Subject: Re: Xilinx Powerpc issue with custom peripherals
From: jetmarc@hotmail.com
Date: Fri, 6 Feb 2009 04:47:30 -0800 (PST)
Links: << >>  << T >>  << A >>
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,
Marc

Article: 138101
Subject: Re: Precedence of signal assignment in a clocked process
From: Enes Erdin <eneserdin@gmail.com>
Date: Fri, 6 Feb 2009 04:51:00 -0800 (PST)
Links: << >>  << T >>  << A >>
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".

--enes

Article: 138102
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: jleslie48 <jon@jonathanleslie.com>
Date: Fri, 6 Feb 2009 05:29:44 -0800 (PST)
Links: << >>  << T >>  << A >>
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 Leslie





Article: 138103
Subject: Re: Experiencing problems when moving an FPGA-based implementation
From: Kim Enkovaara <kim.enkovaara@iki.fi>
Date: Fri, 06 Feb 2009 15:54:57 +0200
Links: << >>  << T >>  << A >>
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.

--Kim

Article: 138104
Subject: Problem within virtex5 LX prototype platform / BPI .
From: bamboutcha9999@hotmail.com
Date: Fri, 6 Feb 2009 06:04:58 -0800 (PST)
Links: << >>  << T >>  << A >>
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 you

Article: 138105
Subject: Re: rs232 uart: testbench vs real world, and the missing first letter.
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 06 Feb 2009 14:20:27 +0000
Links: << >>  << T >>  << A >>
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
Subject: Re: Core interface protocol
From: Manny <mloulah@hotmail.com>
Date: Fri, 6 Feb 2009 06:56:25 -0800 (PST)
Links: << >>  << T >>  << A >>
Thanks for the input, points taken. I'll be giving the Wishbone bus a
go. It's always good to support open source standards.

Manny

Article: 138107
Subject: Re: how to cope with read cycle latency in block ram on Xilinx device
From: ales.gorkic@gmail.com
Date: Fri, 6 Feb 2009 07:09:55 -0800 (PST)
Links: << >>  << T >>  << A >>
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,

Ales

Article: 138108
Subject: Re: how to cope with read cycle latency in block ram on Xilinx device
From: Gabor <gabor@alacron.com>
Date: Fri, 6 Feb 2009 08:26:38 -0800 (PST)
Links: << >>  << T >>  << A >>
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,
Gabor

Article: 138109
Subject: Re: Precedence of signal assignment in a clocked process
From: Mike Treseler <mtreseler@gmail.com>
Date: Fri, 06 Feb 2009 08:34:35 -0800
Links: << >>  << T >>  << A >>
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: 138110
Subject: ISE10.1 not support guide mode Map & PAR ?
From: Marlboro <ccon67@netscape.net>
Date: Fri, 6 Feb 2009 08:34:36 -0800 (PST)
Links: << >>  << T >>  << A >>
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 ?

Article: 138111
Subject: Re: How to divide clock frequency......
From: Gabor <gabor@alacron.com>
Date: Fri, 6 Feb 2009 08:36:44 -0800 (PST)
Links: << >>  << T >>  << A >>
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,
Gabor

Article: 138112
Subject: Re: ISE10.1 not support guide mode Map & PAR ?
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 6 Feb 2009 16:43:38 -0000
Links: << >>  << T >>  << A >>
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
Subject: OPB_LCD missing char? quiz+answer :)
From: Antti <Antti.Lukats@googlemail.com>
Date: Fri, 6 Feb 2009 09:34:24 -0800 (PST)
Links: << >>  << T >>  << A >>


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: 138114
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: jleslie48 <jon@jonathanleslie.com>
Date: Fri, 6 Feb 2009 09:39:09 -0800 (PST)
Links: << >>  << T >>  << A >>
On 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

Jon


Article: 138115
Subject: Re: Precedence of signal assignment in a clocked process
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 06 Feb 2009 17:43:21 +0000
Links: << >>  << T >>  << A >>
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: 138116
Subject: Re: Xilinx Powerpc issue with custom peripherals
From: Lorenz Kolb <lorenz.kolb@uni-ulm.de>
Date: Fri, 06 Feb 2009 19:12:27 +0100
Links: << >>  << T >>  << A >>
ssirowy@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,

Lorenz

Article: 138117
Subject: Re: Experiencing problems when moving an FPGA-based implementation to an ASIC
From: Muzaffer Kal <kal@dspia.com>
Date: Fri, 06 Feb 2009 10:38:49 -0800
Links: << >>  << T >>  << A >>
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.com

Article: 138118
Subject: Re: rs232 uart: testbench vs real world, and the missing first letter.
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 06 Feb 2009 19:16:33 +0000
Links: << >>  << T >>  << A >>
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: 138119
Subject: Recommended Xilinx USB JTAG cable?
From: Eric <jonas@mit.edu>
Date: Fri, 6 Feb 2009 11:53:26 -0800 (PST)
Links: << >>  << T >>  << A >>
I'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,
   ...Eric

Article: 138120
Subject: Req for Recommendations: Modelsim vs IUS & VCS
From: Poojan Wagh <poojanwagh@gmail.com>
Date: Fri, 6 Feb 2009 12:50:50 -0800 (PST)
Links: << >>  << T >>  << A >>
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
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: jleslie48 <jon@jonathanleslie.com>
Date: Fri, 6 Feb 2009 12:56:38 -0800 (PST)
Links: << >>  << T >>  << A >>
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: 138122
Subject: Re: testing a processor
From: "akshay" <akshayvreddy@gmail.com>
Date: Fri, 06 Feb 2009 15:01:43 -0600
Links: << >>  << T >>  << A >>
thank 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 naf
>



Article: 138123
Subject: Re: Precedence of signal assignment in a clocked process
From: Glen Herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 06 Feb 2009 14:24:15 -0700
Links: << >>  << T >>  << A >>
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;


-- glen


Article: 138124
Subject: Re: rs232 uart: testbench vs real world, and the missing first letter.
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Fri, 06 Feb 2009 22:35:59 +0000
Links: << >>  << T >>  << A >>
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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search