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 137975

Article: 137975
Subject: Re: Implementation of Xilinx Aurora protocol with error correction
From: Vladimir Vassilevsky <antispam_bogus@hotmail.com>
Date: Tue, 03 Feb 2009 10:21:47 -0600
Links: << >>  << T >>  << A >>


S. Bernstein wrote:

> Hi,
> 
> I implemented an Aurora link layer using EDK.Now I am concerned about 
> reliability and want to implement a 64-Bit or 32-Bit Hamming Code to enable 
> error detection and correction. Now I am wondering if that makes sense 
> anyway, because if there are bit errors the 8B/10B coding featured in Aurora 
> would dismiss erroneous data words anyway and the Hamming Code would not 
> work. Please correct me if i'm wrong. So what means do I actually have to 
> implement a fail-safe connection via Aurora?

Aurora assumes the link to be error free. If there is an occasional 
error, the connection is re-established. Hence the error correction 
coding is not going to make an improvement. If you are looking for the 
bullet proof link with ECC, you should use a different protocol.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com


Article: 137976
Subject: Re: Digilent Nexys 2 Issue
From: "freespace@gmail.com" <freespace@gmail.com>
Date: Tue, 3 Feb 2009 08:47:12 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 16, 8:00=A0pm, d...@axoninstruments.biz wrote:
> On Jan 15, 9:45=A0am, reganirel...@gmail.com wrote:
>
> > Same with me.
>
> > A staff member from Digilent emailed me with that same link, good as
> > gold now.
>
> > Regan
>
> I guess they had shipped the boards before the software was ready to
> go on the website.
>
> Have fun. No I can start to have a real go at learning VHDL!
>
> Dave...

Ah, so good to see this. I been having issues too:
http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/2525ea564e1=
deda1#

I was worried my board (which passes the onboard diagnostics) was a
waste of money: the adept software will not properly initialise the
scan chain.

Even thought I emailed digilent about it pre-Christmas, I haven't had
an email from the with a link to the new software, which I will try
tomorrow morning. Hope it fixes my woes.

Cheers,
Steve

Article: 137977
Subject: Tabula - new kid on the FPGA block?
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Tue, 03 Feb 2009 16:56:32 +0000
Links: << >>  << T >>  << A >>
Anyone know anything about 

  www.tabula.com

???  They are operating very firmly in "stealth" mode
right now, but they have money, lots of patents and
some high-profile people.

A very quick scan of their patents suggests that they
may be doing something with very fast - truly dynamic -
reconfiguration of FPGA logic; one of the abstracts 
tantalisingly talks about reconfiguration faster 
than the system clock.  Lack of time, and frustration 
with the way the USPTO website fools around with 
QuickTime when you try to view images, has stopped
me from going any further.

Their "early adopter" pages don't seem to be up just yet.

Maybe, just maybe, this and Achronix represent a real
change in the FPGA game.  Interesting.
-- 
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: 137978
Subject: Re: fpga reset
From: Digi Suji <digisuji@gmail.com>
Date: Tue, 3 Feb 2009 09:11:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 2, 11:59=A0pm, "Jan Bruns" <testzugang_janbr...@arcor.de> wrote:
> "Digi Suji":
>
> > I am talking about the whole FPGA being reset in order to reload my
> > design into FPGA again, not resetting my design in the FPGA......here
> > is the data sheet of EEPROM I am using...
> > I get expected results when I do post place and route simulation but
> > not in the hardware...
> > Do you have any suggestions for me?
> > Thanks for your time and help.
>
> Have you tried to track down the error?
> You just said: "powerup: everyting works", "reset: nothing works"
>
> Is there a problem with the the FPGA-configuration, or is
> it a bootloading problem of the fpga-embeded cpu?
>
> Gruss
>
> Jan Bruns

No Jan. I did not figure out the problem. I think it is a problem with
FPGA configuration.

Thanks

Article: 137979
Subject: Re: Why the second flip-flop in Virtex-6?
From: "Jan Bruns" <testzugang_janbruns@arcor.de>
Date: Tue, 3 Feb 2009 18:14:23 +0100
Links: << >>  << T >>  << A >>

"Joseph H Allen":
> Benjamin Couillard  <benjamin.couillard@gmail.com> wrote:
>>On 3 fév, 10:12, jhal...@TheWorld.com (Joseph H Allen) wrote:
>>> I'm surprised that the Spartan-6 integrated memory controller does not support
>>> DIMMs. Also surprised that there are no integrated memory controllers in
>>> Virtex-6.
>>>
>>> Note the Virtex-6 Select-IO voltage range: only up to 2.5V! 2.5V is the
>>> new 5V...
>>
>>3.3V is the new 5V you might say

> No, 3.3V was the old new 5V.  The new new 5V is 2.5V.  Altera Straitx-IV
> also does not support 3.3V I/O.

Hm, ok, the old 5V-TTL logic devices pobably weren't compatible with
tube-level logic.

Gruss

Jan Bruns




Article: 137980
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: jleslie48 <jon@jonathanleslie.com>
Date: Tue, 3 Feb 2009 09:23:55 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 11:01 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:
> On Tue, 3 Feb 2009 07:50:10 -0800 (PST), jleslie48 wrote:
> >> >After a lot of mucking about, I zeroed in on the actual pin/wire that
> >> >the message is going out on,
> >> >and sure enough, there is the first letter "supposedly" going out in
> >> >Testbench, "T" followed by "e" followed
> >> >by "s".  all exactly as it should be: start bit, 8 bits of data, and a
> >> >stop bit, timed exactly at 115200 baud.
>
> >> >Meantime, the real world is missing the first letter.
>
> Sorry, I didn't read that carefully enough the first time.
> Do I understand correctly that you have examined the
> serial line output from the UART, and you are seeing
> the 'T' character - with its start, stop etc - actually
> going out on the line?  If so, then my suggestion about
> buffer overrun is irrelevant and instead you need to ask
> why you are not seeing that character.  Here are some
> possibilities:
>
> 1) It's going out so soon after you powered-up the FPGA
> that the real, physical receiver (which, I assume, is
> a COM port on your PC) has not had time to establish
> an idle-line level.
>
> 2) Ditto, but you have some issue with the modem
> handshake signals (DSR, RTS etc) so that the COM
> receiver doesn't think the line is active at that time.
>
> 3) Look carefully at the serial line output again: is
> it REALLY following the protocol?  At least 11 bit
> times of "mark" followed by the transition to "space"
> at the beginning of the start bit?  I don't know if you
> are using parity, but if so... perhaps there's some
> initialisation issue and the parity is wrong on the
> first character?
>
> A storage 'scope on the serial line, triggered by the
> FPGA's configuration DONE signal going true, might
> yield some insights.
>
> Many an experiment has foundered on the reefs of
> power-up initialisation trouble.
> --
> 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.

+++++++++++++++

> Do I understand correctly that you have examined the
> serial line output from the UART, and you are seeing
> the 'T' character - with its start, stop etc - actually
> going out on the line?  If so, then my suggestion about


NO!!!  I haven't put the output on a oscilliscope yet. I only
meant that I "saw the 'T' character on the TESTBENCH output
line.


>
> 1) It's going out so soon after you powered-up the FPGA
> that the real, physical receiver (which, I assume, is
> a COM port on your PC) has not had time to establish
> an idle-line level.
>
> 2) Ditto, but you have some issue with the modem
> handshake signals (DSR, RTS etc) so that the COM
> receiver doesn't think the line is active at that time.
>
> 3) Look carefully at the serial line output again: is
> it REALLY following the protocol?  At least 11 bit
> times of "mark" followed by the transition to "space"
> at the beginning of the start bit?  I don't know if you
> are using parity, but if so... perhaps there's some
> initialisation issue and the parity is wrong on the
> first character?

I don't think this is the case.  The detail I left out is that if
I leave my associates code alone, viz, If leave in the message
definition as standard logic vector:

------------------------------------------------
  SUBTYPE REG IS STD_LOGIC_VECTOR( 7 DOWNTO 0 );
  TYPE LOKI_PROJECT IS ARRAY ( INTEGER RANGE <> ) OF REG;

  SIGNAL    LOKI_MESS_TRAN       :
STD_LOGIC                           := '0';
  CONSTANT  LOKI_MESS_MAX        :
INTEGER                             := 26;
  SIGNAL    LOKI_MESS_CNT        : INTEGER RANGE 0 TO LOKI_MESS_MAX;
  SIGNAL    PROJECT_NAME         : LOKI_PROJECT( 0 TO LOKI_MESS_MAX )
            :=  ( CR, AL, AO, AK, AI, SP, AP, AR, AO, AJ, AE, AC, AT,
                  CR, AR, AE, AV, AI, AS, AI, AO, AN, SP, N0, N0, N1,
CR );
     IF ( CLK_16_6MHZ = '1' AND CLK_16_6MHZ'EVENT ) THEN
          IF ( UART_RESET_BUFFER   = '0' ) THEN
               IF    ( ( LOKI_MESS_TRAN      = '1' ) AND
                       ( TX_BUFFER_FULL      = '0' ) AND
                       ( TX_WRITE_BUFFER_STB = '0' )  ) THEN
			           TX_DATA_IN( 7 DOWNTO 0 ) <= PROJECT_NAME
( LOKI_MESS_CNT );
--------------------------------------------------------


all works perfectly fine.



its only when I introduce:

--------------------------------------------
  function to_slv(c: character) return std_logic_vector  is
  begin
    return std_logic_vector(to_unsigned(character'pos(c), 8));
  end;

  constant project_name_stg      : string := "Testing 1,2,3,";
  SIGNAL   project_name_cnt      : INTEGER RANGE 1 to
project_name_stg'high;
  SIGNAL   lprj_MESS_TRAN        : STD_LOGIC     := '0';

     IF ( CLK_16_6MHZ = '1' AND CLK_16_6MHZ'EVENT ) THEN
          IF ( UART_RESET_BUFFER   = '0' ) THEN
               IF    ( ( lprj_MESS_TRAN      = '1' ) AND
                       ( TX_BUFFER_FULL      = '0' ) AND
                       ( TX_WRITE_BUFFER_STB = '0' )  ) THEN
			           --TX_DATA_IN( 7 DOWNTO 0 ) <= PROJECT_NAME
( lprj_MESS_CNT );
			           TX_DATA_IN <= to_slv(project_name_stg
( project_name_cnt ));
----------------------------------------------------

That I see the first character missing problem. I don't know why the
'string' version skips the
first character, but the "standard logic vector' version is fine.

And yes I still know I have to bubble up the redundant checks and get
these walks through
the strings straightened out, but I these issues are mutatis mutandis
with both sets of code,
and the Testbench waveforms "look" identical, so I'm at a loss as to
why they behave differently.

Before I streamline code I want the missing first character for
strings issue resolved.


Article: 137981
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: jleslie48 <jon@jonathanleslie.com>
Date: Tue, 3 Feb 2009 09:41:34 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 10:52 am, Mike Treseler <mtrese...@gmail.com> wrote:
> jleslie48 wrote:
> >http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen...
>
> > I see the "T" getting in, to the datastream, but I haven't found where
> > it got clobbered.
>
> Is the reset pulse lined up ok?

Mike,

Not sure what you mean here,

and Jonathan,

Bingo!

I reduce the startup message to
-----------------------------------------------------
  constant project_name_stg      : string := "1";
  SIGNAL   project_name_cnt      : INTEGER RANGE 1 to
project_name_stg'high;
  SIGNAL   lprj_MESS_TRAN        : STD_LOGIC     := '0';
------------------------------------------------------------

just the one character, and it's there.  (good it would of taken me
hours
to figure out the oscilliscope!)

so that would imply that the stop bit (aka, the dead-reckoning delay)
is the issue yes? or is Mike onto the solution?   And why does
the standard logic vector not suffer from the same issue?

Inquiring minds want to know...





Article: 137982
Subject: xilinx platform usb cable linux troubles
From: luudee <rudolf.usselmann@gmail.com>
Date: Tue, 3 Feb 2009 09:54:24 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi All,

this seems to be a new problem I am seeing with ISE 10.1 sp3.

I have libusb installed on my Fedora 7 x86_64 box, and impact
used to work. Since sp3 update, the usb cable does not work
anymore.

When I plug in the cable it appears to enumerate, but when I
try to connect to my development board, it fails:

 Using libusb.
Connecting to cable (Usb Port - USB21).
Checking cable driver.
File version of /tools/Xilinx_10.1_x86_64/ISE/bin/lin64/xusbdfwu.hex =
1030.
File version of /etc/hotplug/usb/xusbdfwu.fw/xusbdfwu.hex = 1030.
 Using libusb.
 Max current requested during enumeration is 74 mA.
Type = 0x0004.
 Cable Type = 3, Revision = 0.
 Setting cable speed to 6 MHz.
Cable connection established.
Firmware version = 1303.
File version of /tools/Xilinx_10.1_x86_64/ISE/data/xusb_xlp.hex =
1303.
Firmware hex file version = 1303.
PLD file version = 0012h.
 PLD version = 0012h.
bulk tranfer failed, endpoint=02.
write count != nBytes(0), rc = 20000020.
write cmd failed 20000020.
control tranfer failed.
write cmdbuffer failed 20000020.
Error reading reference voltage level.
Elapsed time =      3 sec.
control tranfer failed.
write cmdbuffer failed 20000020.
Elapsed time =      3 sec.



And on the console I get:
usb 1-2.1.3: usbfs: USBDEVFS_CONTROL failed cmd _impact rqt 192 rq 176
len 1 ret -110
usb 1-2.1.3: usbfs: USBDEVFS_CONTROL failed cmd _impact rqt 64 rq 176
len 0 ret -110


Any suggestion or ideas what is causing that ?

Thanks,
rudi

Article: 137983
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: "Thomas J. Gritzan" <phygon_antispam@gmx.de>
Date: Tue, 03 Feb 2009 19:40:01 +0100
Links: << >>  << T >>  << A >>
jleslie48 wrote:
> --------------------------------------------
>   function to_slv(c: character) return std_logic_vector  is
>   begin
>     return std_logic_vector(to_unsigned(character'pos(c), 8));
>   end;
> 
>   constant project_name_stg      : string := "Testing 1,2,3,";
>   SIGNAL   project_name_cnt      : INTEGER RANGE 1 to
> project_name_stg'high;
>   SIGNAL   lprj_MESS_TRAN        : STD_LOGIC     := '0';
> 
>      IF ( CLK_16_6MHZ = '1' AND CLK_16_6MHZ'EVENT ) THEN
>           IF ( UART_RESET_BUFFER   = '0' ) THEN
>                IF    ( ( lprj_MESS_TRAN      = '1' ) AND
>                        ( TX_BUFFER_FULL      = '0' ) AND
>                        ( TX_WRITE_BUFFER_STB = '0' )  ) THEN
> 			           --TX_DATA_IN( 7 DOWNTO 0 ) <= PROJECT_NAME
> ( lprj_MESS_CNT );
> 			           TX_DATA_IN <= to_slv(project_name_stg
> ( project_name_cnt ));
> ----------------------------------------------------
> 
> That I see the first character missing problem. I don't know why the
> 'string' version skips the
> first character, but the "standard logic vector' version is fine.

Do you initialize project_name_cnt somewhere?

-- 
Thomas

Article: 137984
Subject: Re: Why the second flip-flop in Virtex-6?
From: Jan Pech <invalid@void.domain>
Date: Tue, 03 Feb 2009 19:49:23 +0100
Links: << >>  << T >>  << A >>

On Tue, 2009-02-03 at 15:12 +0000, Joseph H Allen wrote:
> I'm surprised that the Spartan-6 integrated memory controller does not support
> DIMMs.  Also surprised that there are no integrated memory controllers in
> Virtex-6.
> 

I am not. From my experience with Virtex-5 and Spartan-3 I can say that
Spartans are terribly slow. If you put MPMC into Virtex-5, you can reach
pretty high data throughput. With a bit complex design in Spartan-3A you
will have hard time to meet at least minimum clock frequency for DDR2
devices. Hard-core memory controller in next generation Spartan devices
might help a lot.

Jan


> Note the Virtex-6 Select-IO voltage range: only up to 2.5V!  2.5V is the
> new 5V...
> 
> 


Article: 137985
Subject: Re: FFT core has reversed output data
From: "kristian" <kris11@gmx.de>
Date: Tue, 03 Feb 2009 12:53:44 -0600
Links: << >>  << T >>  << A >>

>>
>> Kris,
>>
>> No idea about the details of the Xilinx core, but if you have real
>> valued input data and complex output data, you can expect that the
>> output (if you reverse the output samples, with the DC value at the
>> middle) is the negative complex conjugate (see Wikipedia or a standard
>> textbook). That means you could just swap the real and imaginary
>> output, assuming it's a real bug that you want to hack up a fix for.
>
>Mental misfire... negative complex conjugate is just inverting the
>real part; no swap required.
>
>>
>> Alternatively, the behaviour you describe for a simple sinusoid could
>> be correct, since you didn't specify the start phase. A sinusoid
>> that's off by 180 degrees (pi radians) will have its value (dirac fft
>> coeffs) multiplied by exp(i*pi) =3D -1.
>>
>> =A0- Kenn
>
>

Hi Kenn,

to verify the results of the fft core I used a java applet
(http://sepwww.stanford.edu/oldsep/hale/FftLab.html). When I put at the
input of the core a sinus for the real part and a cosinus for the imaginary
part then the java applet show only a positiv dirac puls at x(k) at the
imaginary frequency domain. This result I also expect at the fft core
output. But I get at x(N-k) a positiv dirac puls.

Regards,
Kris

Article: 137986
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: jleslie48 <jon@jonathanleslie.com>
Date: Tue, 3 Feb 2009 10:56:29 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 1:40 pm, "Thomas J. Gritzan" <phygon_antis...@gmx.de> wrote:
> jleslie48 wrote:
> > --------------------------------------------
> >   function to_slv(c: character) return std_logic_vector  is
> >   begin
> >     return std_logic_vector(to_unsigned(character'pos(c), 8));
> >   end;
>
> >   constant project_name_stg      : string := "Testing 1,2,3,";
> >   SIGNAL   project_name_cnt      : INTEGER RANGE 1 to
> > project_name_stg'high;
> >   SIGNAL   lprj_MESS_TRAN        : STD_LOGIC     := '0';
>
> >      IF ( CLK_16_6MHZ = '1' AND CLK_16_6MHZ'EVENT ) THEN
> >           IF ( UART_RESET_BUFFER   = '0' ) THEN
> >                IF    ( ( lprj_MESS_TRAN      = '1' ) AND
> >                        ( TX_BUFFER_FULL      = '0' ) AND
> >                        ( TX_WRITE_BUFFER_STB = '0' )  ) THEN
> >                               --TX_DATA_IN( 7 DOWNTO 0 ) <= PROJECT_NAME
> > ( lprj_MESS_CNT );
> >                               TX_DATA_IN <= to_slv(project_name_stg
> > ( project_name_cnt ));
> > ----------------------------------------------------
>
> > That I see the first character missing problem. I don't know why the
> > 'string' version skips the
> > first character, but the "standard logic vector' version is fine.
>
> Do you initialize project_name_cnt somewhere?
>
> --
> Thomas

good thought but here:
----------------------------------------
-------------------------------------------------------------------------------------------------
--  INITIALIZING lprj PROJECT MESSAGE COUNT  ( project_name_cnt )
-------------------------------------------------------------------------------------------------


P10:  PROCESS ( CLK_16_6MHZ, UART_RESET_BUFFER, UART_RESET_NEXT,
lprj_MESS_TRAN, TX_WRITE_BUFFER_STB )
BEGIN
     IF ( CLK_16_6MHZ = '1' AND CLK_16_6MHZ'EVENT ) THEN
          IF ( ( UART_RESET_BUFFER = '0' ) AND
               ( UART_RESET_NEXT   = '1' )  )  THEN
                      project_name_cnt <= 1; --project_name_cnt'low;

          ELSIF ( ( lprj_MESS_TRAN      = '1'              ) AND
                  ( TX_WRITE_BUFFER_STB = '1'              ) AND
                  ( project_name_cnt      /=
project_name_stg'high   )  ) THEN
                      project_name_cnt <= ( project_name_cnt + 1 );
          END IF;
     END IF;
END PROCESS P10;

------------------------------------------------------

here's the entire source code file:

http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/source/LOKI_Top.vhd


Article: 137987
Subject: Re: Why the second flip-flop in Virtex-6?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 3 Feb 2009 19:07:10 +0000 (UTC)
Links: << >>  << T >>  << A >>
Jan Pech <invalid@void.domain> wrote:
 
> I am not. From my experience with Virtex-5 and Spartan-3 I can say that
> Spartans are terribly slow. If you put MPMC into Virtex-5, you can reach
> pretty high data throughput. With a bit complex design in Spartan-3A you
> will have hard time to meet at least minimum clock frequency for DDR2
> devices. Hard-core memory controller in next generation Spartan devices
> might help a lot.

The Digilent Spartan3E board has on board DDR RAM.

I believe DDR, not DDR2, though, but presumably they believe
the 3E can do that.  I haven't tried it yet.

-- glen

Article: 137988
Subject: Re: Selecting a starter FPGA board
From: Bryan <bryan.fletcher@avnet.com>
Date: Tue, 3 Feb 2009 11:18:48 -0800 (PST)
Links: << >>  << T >>  << A >>
Waiting for Spartan-6 is certainly a good option.  If you don't want
to wait, then I would suggest the Spartan-3A DSP Starter board.  This
has an 1800 part, which is bigger than the FPGA on the obsolete 1600E
board.  It has VGA and ethernet.  No PS/2 but it has lots of I/Os on a
variety of expansion headers.

www.em.avnet.com/spartan3a-dsp

Board is $295.  The 1800A is supported in WebPack.  You'll need a JTAG
cable if you don't already own one ($225)
 
http://www.em.avnet.com/evk/home/0,1719,RID%253D0%2526CID%253D47236%2526CAT%253D%2526CCD%253DUSA%2526SID%253D32214%2526DID%253DDF2%2526SRT%253D1%2526LID%253D32232%2526PRT%253D0%2526PVW%253D%2526PNT%253D%2526BID%253DDF2%2526CTP%253DEVK,00.html

Bryan

Article: 137989
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: jleslie48 <jon@jonathanleslie.com>
Date: Tue, 3 Feb 2009 11:19:51 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 12:41 pm, jleslie48 <j...@jonathanleslie.com> wrote:
> On Feb 3, 10:52 am, Mike Treseler <mtrese...@gmail.com> wrote:
>
> > jleslie48 wrote:
> > >http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen...
>
> > > I see the "T" getting in, to the datastream, but I haven't found where
> > > it got clobbered.
>
> > Is the reset pulse lined up ok?
>
> Mike,
>
> Not sure what you mean here,
>
> and Jonathan,
>
> Bingo!
>
> I reduce the startup message to
> -----------------------------------------------------
>   constant project_name_stg      : string := "1";
>   SIGNAL   project_name_cnt      : INTEGER RANGE 1 to
> project_name_stg'high;
>   SIGNAL   lprj_MESS_TRAN        : STD_LOGIC     := '0';
> ------------------------------------------------------------
>
> just the one character, and it's there.  (good it would of taken me
> hours
> to figure out the oscilliscope!)
>
> so that would imply that the stop bit (aka, the dead-reckoning delay)
> is the issue yes? or is Mike onto the solution?   And why does
> the standard logic vector not suffer from the same issue?
>
> Inquiring minds want to know...

Ok,

the mystery gets deeper.

I make the message string:
  constant project_name_stg      : string := "123456789a12345";

aka, 15 characters, all is well.
I make it 16 characters:
  constant project_name_stg      : string := "123456789a123456";

my output becomes:
23456789a1234561

were the 1 at the end is indeed the first character not the last.





Article: 137990
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: Dave Pollum <vze24h5m@verizon.net>
Date: Tue, 3 Feb 2009 11:21:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 1:56 pm, jleslie48 <j...@jonathanleslie.com> wrote:
> On Feb 3, 1:40 pm, "Thomas J. Gritzan" <phygon_antis...@gmx.de> wrote:
>
>
>
> > jleslie48 wrote:
> > > --------------------------------------------
> > >   function to_slv(c: character) return std_logic_vector  is
> > >   begin
> > >     return std_logic_vector(to_unsigned(character'pos(c), 8));
> > >   end;
>
> > >   constant project_name_stg      : string :=3D "Testing 1,2,3,";
> > >   SIGNAL   project_name_cnt      : INTEGER RANGE 1 to
> > > project_name_stg'high;
> > >   SIGNAL   lprj_MESS_TRAN        : STD_LOGIC     :=3D '0';
>
> > >      IF ( CLK_16_6MHZ =3D '1' AND CLK_16_6MHZ'EVENT ) THEN
> > >           IF ( UART_RESET_BUFFER   =3D '0' ) THEN
> > >                IF    ( ( lprj_MESS_TRAN      =3D '1' ) AND
> > >                        ( TX_BUFFER_FULL      =3D '0' ) AND
> > >                        ( TX_WRITE_BUFFER_STB =3D '0' )  ) THEN
> > >                               --TX_DATA_IN( 7 DOWNTO 0 ) <=3D PROJECT=
_NAME
> > > ( lprj_MESS_CNT );
> > >                               TX_DATA_IN <=3D to_slv(project_name_stg
> > > ( project_name_cnt ));
> > > ----------------------------------------------------
>
> > > That I see the first character missing problem. I don't know why the
> > > 'string' version skips the
> > > first character, but the "standard logic vector' version is fine.
>
> > Do you initialize project_name_cnt somewhere?
>
> > --
> > Thomas
>
> good thought but here:
> ----------------------------------------
> -------------------------------------------------------------------------=
------------------------
> --  INITIALIZING lprj PROJECT MESSAGE COUNT  ( project_name_cnt )
> -------------------------------------------------------------------------=
------------------------
>
> P10:  PROCESS ( CLK_16_6MHZ, UART_RESET_BUFFER, UART_RESET_NEXT,
> lprj_MESS_TRAN, TX_WRITE_BUFFER_STB )
> BEGIN
>      IF ( CLK_16_6MHZ =3D '1' AND CLK_16_6MHZ'EVENT ) THEN
>           IF ( ( UART_RESET_BUFFER =3D '0' ) AND
>                ( UART_RESET_NEXT   =3D '1' )  )  THEN
>                       project_name_cnt <=3D 1; --project_name_cnt'low;
>
>           ELSIF ( ( lprj_MESS_TRAN      =3D '1'              ) AND
>                   ( TX_WRITE_BUFFER_STB =3D '1'              ) AND
>                   ( project_name_cnt      /=3D
> project_name_stg'high   )  ) THEN
>                       project_name_cnt <=3D ( project_name_cnt + 1 );
>           END IF;
>      END IF;
> END PROCESS P10;
>
> ------------------------------------------------------
>
> here's the entire source code file:
>
> http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/source/LOKI_Top.vhd
------------------------------??? ------------------------
One quick thing I noticed in process "P5":
P5:  PROCESS ( CLK_16_6MHZ )
BEGIN
     IF ( CLK_16_6MHZ =3D '1' AND CLK_16_6MHZ'EVENT ) THEN
          IF ( RESET_COUNT( 3 DOWNTO 0 ) =3D "1111" ) THEN
               RESET_COUNT( 3 DOWNTO 0 ) <=3D "1111";
               UART_RESET_BUFFER         <=3D '0';
          ELSE
               RESET_COUNT( 3 DOWNTO 0 ) <=3D RESET_COUNT( 3 DOWNTO 0 )
+ 1 ;
               UART_RESET_BUFFER         <=3D '1';
          END IF;
     END IF;
END PROCESS P5;
------------------------------------???------------------------------=A2=BC
The 2nd IF says that if RESET_COUNT is all 1's, then set it to all
1's.  I think that you meant to set it to all 0's.  BTW, you don't
need  "...(3 downto 0)..." because the signal is defined as (3 downto
0).
so.....

BEGIN
     IF ( rising_edge( CLK_16_6MHZ ) ) THEN
          IF ( RESET_COUNT =3D "1111" ) THEN
               RESET_COUNT                <=3D (others =3D> '0');  -- ALL
bits to '0'
               UART_RESET_BUFFER   <=3D '0';
          ELSE
               RESET_COUNT                <=3D RESET_COUNT + 1 ;
               UART_RESET_BUFFER   <=3D '1';
          END IF;
     END IF;
--------------------
HTH
-Dave Pollum




Article: 137991
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: jleslie48 <jon@jonathanleslie.com>
Date: Tue, 3 Feb 2009 11:24:17 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 2:19 pm, jleslie48 <j...@jonathanleslie.com> wrote:
> On Feb 3, 12:41 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
>
>
> > On Feb 3, 10:52 am, Mike Treseler <mtrese...@gmail.com> wrote:
>
> > > jleslie48 wrote:
> > > >http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screen...
>
> > > > I see the "T" getting in, to the datastream, but I haven't found where
> > > > it got clobbered.
>
> > > Is the reset pulse lined up ok?
>
> > Mike,
>
> > Not sure what you mean here,
>
> > and Jonathan,
>
> > Bingo!
>
> > I reduce the startup message to
> > -----------------------------------------------------
> >   constant project_name_stg      : string := "1";
> >   SIGNAL   project_name_cnt      : INTEGER RANGE 1 to
> > project_name_stg'high;
> >   SIGNAL   lprj_MESS_TRAN        : STD_LOGIC     := '0';
> > ------------------------------------------------------------
>
> > just the one character, and it's there.  (good it would of taken me
> > hours
> > to figure out the oscilliscope!)
>
> > so that would imply that the stop bit (aka, the dead-reckoning delay)
> > is the issue yes? or is Mike onto the solution?   And why does
> > the standard logic vector not suffer from the same issue?
>
> > Inquiring minds want to know...
>
> Ok,
>
> the mystery gets deeper.
>
> I make the message string:
>   constant project_name_stg      : string := "123456789a12345";
>
> aka, 15 characters, all is well.
> I make it 16 characters:
>   constant project_name_stg      : string := "123456789a123456";
>
> my output becomes:
> 23456789a1234561
>
> were the 1 at the end is indeed the first character not the last.

and the string:
 constant project_name_stg      : string := "f23456789a1234567";
yields the output:
23456789a1234567

I imagine 17 or more is destructive to the first character.



Article: 137992
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: jleslie48 <jon@jonathanleslie.com>
Date: Tue, 3 Feb 2009 11:43:33 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 2:21 pm, Dave Pollum <vze24...@verizon.net> wrote:
> On Feb 3, 1:56 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
> > On Feb 3, 1:40 pm, "Thomas J. Gritzan" <phygon_antis...@gmx.de> wrote:
>
> > > jleslie48 wrote:
> > > > --------------------------------------------
> > > >   function to_slv(c: character) return std_logic_vector  is
> > > >   begin
> > > >     return std_logic_vector(to_unsigned(character'pos(c), 8));
> > > >   end;
>
> > > >   constant project_name_stg      : string :=3D "Testing 1,2,3,";
> > > >   SIGNAL   project_name_cnt      : INTEGER RANGE 1 to
> > > > project_name_stg'high;
> > > >   SIGNAL   lprj_MESS_TRAN        : STD_LOGIC     :=3D '0';
>
> > > >      IF ( CLK_16_6MHZ =3D '1' AND CLK_16_6MHZ'EVENT ) THEN
> > > >           IF ( UART_RESET_BUFFER   =3D '0' ) THEN
> > > >                IF    ( ( lprj_MESS_TRAN      =3D '1' ) AND
> > > >                        ( TX_BUFFER_FULL      =3D '0' ) AND
> > > >                        ( TX_WRITE_BUFFER_STB =3D '0' )  ) THEN
> > > >                               --TX_DATA_IN( 7 DOWNTO 0 ) <=3D PROJE=
CT_NAME
> > > > ( lprj_MESS_CNT );
> > > >                               TX_DATA_IN <=3D to_slv(project_name_s=
tg
> > > > ( project_name_cnt ));
> > > > ----------------------------------------------------
>
> > > > That I see the first character missing problem. I don't know why th=
e
> > > > 'string' version skips the
> > > > first character, but the "standard logic vector' version is fine.
>
> > > Do you initialize project_name_cnt somewhere?
>
> > > --
> > > Thomas
>
> > good thought but here:
> > ----------------------------------------
> > -----------------------------------------------------------------------=
--------------------------
> > --  INITIALIZING lprj PROJECT MESSAGE COUNT  ( project_name_cnt )
> > -----------------------------------------------------------------------=
--------------------------
>
> > P10:  PROCESS ( CLK_16_6MHZ, UART_RESET_BUFFER, UART_RESET_NEXT,
> > lprj_MESS_TRAN, TX_WRITE_BUFFER_STB )
> > BEGIN
> >      IF ( CLK_16_6MHZ =3D '1' AND CLK_16_6MHZ'EVENT ) THEN
> >           IF ( ( UART_RESET_BUFFER =3D '0' ) AND
> >                ( UART_RESET_NEXT   =3D '1' )  )  THEN
> >                       project_name_cnt <=3D 1; --project_name_cnt'low;
>
> >           ELSIF ( ( lprj_MESS_TRAN      =3D '1'              ) AND
> >                   ( TX_WRITE_BUFFER_STB =3D '1'              ) AND
> >                   ( project_name_cnt      /=3D
> > project_name_stg'high   )  ) THEN
> >                       project_name_cnt <=3D ( project_name_cnt + 1 );
> >           END IF;
> >      END IF;
> > END PROCESS P10;
>
> > ------------------------------------------------------
>
> > here's the entire source code file:
>
> >http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/source/LOKI_Top.vhd
>
> ------------------------------??? ------------------------
> One quick thing I noticed in process "P5":
> P5:  PROCESS ( CLK_16_6MHZ )
> BEGIN
>      IF ( CLK_16_6MHZ =3D '1' AND CLK_16_6MHZ'EVENT ) THEN
>           IF ( RESET_COUNT( 3 DOWNTO 0 ) =3D "1111" ) THEN
>                RESET_COUNT( 3 DOWNTO 0 ) <=3D "1111";
>                UART_RESET_BUFFER         <=3D '0';
>           ELSE
>                RESET_COUNT( 3 DOWNTO 0 ) <=3D RESET_COUNT( 3 DOWNTO 0 )
> + 1 ;
>                UART_RESET_BUFFER         <=3D '1';
>           END IF;
>      END IF;
> END PROCESS P5;
> ------------------------------------???------------------------------=A2=
=BC
> The 2nd IF says that if RESET_COUNT is all 1's, then set it to all
> 1's.  I think that you meant to set it to all 0's.  BTW, you don't
> need  "...(3 downto 0)..." because the signal is defined as (3 downto
> 0).
> so.....
>
> BEGIN
>      IF ( rising_edge( CLK_16_6MHZ ) ) THEN
>           IF ( RESET_COUNT =3D "1111" ) THEN
>                RESET_COUNT                <=3D (others =3D> '0');  -- ALL
> bits to '0'
>                UART_RESET_BUFFER   <=3D '0';
>           ELSE
>                RESET_COUNT                <=3D RESET_COUNT + 1 ;
>                UART_RESET_BUFFER   <=3D '1';
>           END IF;
>      END IF;
> --------------------
> HTH
> -Dave Pollum

well certainly:

~          IF ( RESET_COUNT( 3 DOWNTO 0 ) =3D "1111" ) THEN
 ~              RESET_COUNT( 3 DOWNTO 0 ) <=3D "1111";

makes no sense.  and 'something' bad happens when the 16th character
is in the buffer, so this is definitely a near hit at least. lets see
how
reset_count, uart_reset_buffer are used...


Article: 137993
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: jleslie48 <jon@jonathanleslie.com>
Date: Tue, 3 Feb 2009 12:08:35 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 2:43 pm, jleslie48 <j...@jonathanleslie.com> wrote:
> On Feb 3, 2:21 pm, Dave Pollum <vze24...@verizon.net> wrote:
>
>
>
> > On Feb 3, 1:56 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
> > > On Feb 3, 1:40 pm, "Thomas J. Gritzan" <phygon_antis...@gmx.de> wrote=
:
>
> > > > jleslie48 wrote:
> > > > > --------------------------------------------
> > > > >   function to_slv(c: character) return std_logic_vector  is
> > > > >   begin
> > > > >     return std_logic_vector(to_unsigned(character'pos(c), 8));
> > > > >   end;
>
> > > > >   constant project_name_stg      : string :=3D "Testing 1,2,3,";
> > > > >   SIGNAL   project_name_cnt      : INTEGER RANGE 1 to
> > > > > project_name_stg'high;
> > > > >   SIGNAL   lprj_MESS_TRAN        : STD_LOGIC     :=3D '0';
>
> > > > >      IF ( CLK_16_6MHZ =3D '1' AND CLK_16_6MHZ'EVENT ) THEN
> > > > >           IF ( UART_RESET_BUFFER   =3D '0' ) THEN
> > > > >                IF    ( ( lprj_MESS_TRAN      =3D '1' ) AND
> > > > >                        ( TX_BUFFER_FULL      =3D '0' ) AND
> > > > >                        ( TX_WRITE_BUFFER_STB =3D '0' )  ) THEN
> > > > >                               --TX_DATA_IN( 7 DOWNTO 0 ) <=3D PRO=
JECT_NAME
> > > > > ( lprj_MESS_CNT );
> > > > >                               TX_DATA_IN <=3D to_slv(project_name=
_stg
> > > > > ( project_name_cnt ));
> > > > > ----------------------------------------------------
>
> > > > > That I see the first character missing problem. I don't know why =
the
> > > > > 'string' version skips the
> > > > > first character, but the "standard logic vector' version is fine.
>
> > > > Do you initialize project_name_cnt somewhere?
>
> > > > --
> > > > Thomas
>
> > > good thought but here:
> > > ----------------------------------------
> > > ---------------------------------------------------------------------=
----------------------------
> > > --  INITIALIZING lprj PROJECT MESSAGE COUNT  ( project_name_cnt )
> > > ---------------------------------------------------------------------=
----------------------------
>
> > > P10:  PROCESS ( CLK_16_6MHZ, UART_RESET_BUFFER, UART_RESET_NEXT,
> > > lprj_MESS_TRAN, TX_WRITE_BUFFER_STB )
> > > BEGIN
> > >      IF ( CLK_16_6MHZ =3D '1' AND CLK_16_6MHZ'EVENT ) THEN
> > >           IF ( ( UART_RESET_BUFFER =3D '0' ) AND
> > >                ( UART_RESET_NEXT   =3D '1' )  )  THEN
> > >                       project_name_cnt <=3D 1; --project_name_cnt'low=
;
>
> > >           ELSIF ( ( lprj_MESS_TRAN      =3D '1'              ) AND
> > >                   ( TX_WRITE_BUFFER_STB =3D '1'              ) AND
> > >                   ( project_name_cnt      /=3D
> > > project_name_stg'high   )  ) THEN
> > >                       project_name_cnt <=3D ( project_name_cnt + 1 );
> > >           END IF;
> > >      END IF;
> > > END PROCESS P10;
>
> > > ------------------------------------------------------
>
> > > here's the entire source code file:
>
> > >http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/source/LOKI_Top.v=
hd
>
> > ------------------------------??? ------------------------
> > One quick thing I noticed in process "P5":
> > P5:  PROCESS ( CLK_16_6MHZ )
> > BEGIN
> >      IF ( CLK_16_6MHZ =3D '1' AND CLK_16_6MHZ'EVENT ) THEN
> >           IF ( RESET_COUNT( 3 DOWNTO 0 ) =3D "1111" ) THEN
> >                RESET_COUNT( 3 DOWNTO 0 ) <=3D "1111";
> >                UART_RESET_BUFFER         <=3D '0';
> >           ELSE
> >                RESET_COUNT( 3 DOWNTO 0 ) <=3D RESET_COUNT( 3 DOWNTO 0 )
> > + 1 ;
> >                UART_RESET_BUFFER         <=3D '1';
> >           END IF;
> >      END IF;
> > END PROCESS P5;
> > ------------------------------------???------------------------------=
=A2=BC
> > The 2nd IF says that if RESET_COUNT is all 1's, then set it to all
> > 1's.  I think that you meant to set it to all 0's.  BTW, you don't
> > need  "...(3 downto 0)..." because the signal is defined as (3 downto
> > 0).
> > so.....
>
> > BEGIN
> >      IF ( rising_edge( CLK_16_6MHZ ) ) THEN
> >           IF ( RESET_COUNT =3D "1111" ) THEN
> >                RESET_COUNT                <=3D (others =3D> '0');  -- A=
LL
> > bits to '0'
> >                UART_RESET_BUFFER   <=3D '0';
> >           ELSE
> >                RESET_COUNT                <=3D RESET_COUNT + 1 ;
> >                UART_RESET_BUFFER   <=3D '1';
> >           END IF;
> >      END IF;
> > --------------------
> > HTH
> > -Dave Pollum
>
> well certainly:
>
> ~          IF ( RESET_COUNT( 3 DOWNTO 0 ) =3D "1111" ) THEN
>  ~              RESET_COUNT( 3 DOWNTO 0 ) <=3D "1111";
>
> makes no sense.  and 'something' bad happens when the 16th character
> is in the buffer, so this is definitely a near hit at least. lets see
> how
> reset_count, uart_reset_buffer are used...

Ok this is a fking mess.

what was done here was this, the "program" starts with
uart_reset_buffer
and uart_reset_next high, and the p5 process counts for 16  clock
pulses
to allow the system to startup.  on the 16th pulse (=3D'1111')
uart_reset_buffer
goes low, and as a result of the D-FF that is made up on P6,
uart_reset_next
waits one clock pulse to go low.  So for 1 and only 1 clock pulse,

          IF ( ( UART_RESET_BUFFER =3D '0' ) AND
               ( UART_RESET_NEXT   =3D '1' )  )  THEN

is true. This is the trigger for the "hello world" message.

Now I imagine there *must* be a better way to do this, and Jonathan B.
has
already pointed out  that his section of code is, in technical terms,
higgley-piggley,
but it is not causing my current flub.




Article: 137994
Subject: Re: picoblaze q's
From: uraniumore238@gmail.com
Date: Tue, 3 Feb 2009 12:36:41 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 25, 11:07=A0pm, backhus <n...@nirgends.xyz> wrote:
> Hi,
> for such an application as controlling a display, a programmable
> solution like using a picoblaze is much more flexible than designing a
> dedicated FSM.
> There is an application note (at least for the Spartan 3E Starter Kit)
> that should work for you. Give it a try first.
>
> When it works continue like this:
>
> Expand the design with four Input ports to read in your counter value
>
> Write an assembler routine that converts your binary value to the code
> representation needed by the display ( maybe ASCII).
>
> Change the existing code to read in the ports and call your converting
> routine at a certain time. (Maybe your counter has a Ripple Output or
> EndCount Signal that you can feed to the Interrupt input of the picoblaze=
.)
>
> Have a nice synthesis
> =A0 =A0Eilert
>
> uraniumore...@gmail.com schrieb:
>
>
>
> > Hi All,
>
> > I am trying to understand how to use the picoblaze soft-core. I have a
> > verilog program that uses a counter and stops at a predicted value
> > ( positive or negative). The value of this counter I would like to
> > display on the LCD display of my SPARTAN 3AN. Is there a more simple
> > way to do this than the picoblaze route ? If picoblaze is the best way
> > to go, can someone please explain to me, step-by-step, how I would
> > change the picpblaze code to display the value of the register. Please
> > note that the 32'bit register value can be either presented as a
> > negative value or positive decimal value.
>
> > Thanks!- Hide quoted text -
>
> - Show quoted text -

Okay, the design works.

Expand which design ? Do you mean my .psm or the the verilog file that
instantiates the picoblaze?







Article: 137995
Subject: Re: rs232 uart: testbench vs real world, and the missing first
From: jleslie48 <jon@jonathanleslie.com>
Date: Tue, 3 Feb 2009 13:21:25 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 3, 3:08 pm, jleslie48 <j...@jonathanleslie.com> wrote:
> On Feb 3, 2:43 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
>
>
> > On Feb 3, 2:21 pm, Dave Pollum <vze24...@verizon.net> wrote:
>
> > > On Feb 3, 1:56 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
> > > > On Feb 3, 1:40 pm, "Thomas J. Gritzan" <phygon_antis...@gmx.de> wro=
te:
>
> > > > > jleslie48 wrote:
> > > > > > --------------------------------------------
> > > > > >   function to_slv(c: character) return std_logic_vector  is
> > > > > >   begin
> > > > > >     return std_logic_vector(to_unsigned(character'pos(c), 8));
> > > > > >   end;
>
> > > > > >   constant project_name_stg      : string :=3D "Testing 1,2,3,"=
;
> > > > > >   SIGNAL   project_name_cnt      : INTEGER RANGE 1 to
> > > > > > project_name_stg'high;
> > > > > >   SIGNAL   lprj_MESS_TRAN        : STD_LOGIC     :=3D '0';
>
> > > > > >      IF ( CLK_16_6MHZ =3D '1' AND CLK_16_6MHZ'EVENT ) THEN
> > > > > >           IF ( UART_RESET_BUFFER   =3D '0' ) THEN
> > > > > >                IF    ( ( lprj_MESS_TRAN      =3D '1' ) AND
> > > > > >                        ( TX_BUFFER_FULL      =3D '0' ) AND
> > > > > >                        ( TX_WRITE_BUFFER_STB =3D '0' )  ) THEN
> > > > > >                               --TX_DATA_IN( 7 DOWNTO 0 ) <=3D P=
ROJECT_NAME
> > > > > > ( lprj_MESS_CNT );
> > > > > >                               TX_DATA_IN <=3D to_slv(project_na=
me_stg
> > > > > > ( project_name_cnt ));
> > > > > > ----------------------------------------------------
>
> > > > > > That I see the first character missing problem. I don't know wh=
y the
> > > > > > 'string' version skips the
> > > > > > first character, but the "standard logic vector' version is fin=
e.
>
> > > > > Do you initialize project_name_cnt somewhere?
>
> > > > > --
> > > > > Thomas
>
> > > > good thought but here:
> > > > ----------------------------------------
> > > > -------------------------------------------------------------------=
------------------------------
> > > > --  INITIALIZING lprj PROJECT MESSAGE COUNT  ( project_name_cnt )
> > > > -------------------------------------------------------------------=
------------------------------
>
> > > > P10:  PROCESS ( CLK_16_6MHZ, UART_RESET_BUFFER, UART_RESET_NEXT,
> > > > lprj_MESS_TRAN, TX_WRITE_BUFFER_STB )
> > > > BEGIN
> > > >      IF ( CLK_16_6MHZ =3D '1' AND CLK_16_6MHZ'EVENT ) THEN
> > > >           IF ( ( UART_RESET_BUFFER =3D '0' ) AND
> > > >                ( UART_RESET_NEXT   =3D '1' )  )  THEN
> > > >                       project_name_cnt <=3D 1; --project_name_cnt'l=
ow;
>
> > > >           ELSIF ( ( lprj_MESS_TRAN      =3D '1'              ) AND
> > > >                   ( TX_WRITE_BUFFER_STB =3D '1'              ) AND
> > > >                   ( project_name_cnt      /=3D
> > > > project_name_stg'high   )  ) THEN
> > > >                       project_name_cnt <=3D ( project_name_cnt + 1 =
);
> > > >           END IF;
> > > >      END IF;
> > > > END PROCESS P10;
>
> > > > ------------------------------------------------------
>
> > > > here's the entire source code file:
>
> > > >http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/source/LOKI_Top=
.vhd
>
> > > ------------------------------??? ------------------------
> > > One quick thing I noticed in process "P5":
> > > P5:  PROCESS ( CLK_16_6MHZ )
> > > BEGIN
> > >      IF ( CLK_16_6MHZ =3D '1' AND CLK_16_6MHZ'EVENT ) THEN
> > >           IF ( RESET_COUNT( 3 DOWNTO 0 ) =3D "1111" ) THEN
> > >                RESET_COUNT( 3 DOWNTO 0 ) <=3D "1111";
> > >                UART_RESET_BUFFER         <=3D '0';
> > >           ELSE
> > >                RESET_COUNT( 3 DOWNTO 0 ) <=3D RESET_COUNT( 3 DOWNTO 0=
 )
> > > + 1 ;
> > >                UART_RESET_BUFFER         <=3D '1';
> > >           END IF;
> > >      END IF;
> > > END PROCESS P5;
> > > ------------------------------------???------------------------------=
=A2=BC
> > > The 2nd IF says that if RESET_COUNT is all 1's, then set it to all
> > > 1's.  I think that you meant to set it to all 0's.  BTW, you don't
> > > need  "...(3 downto 0)..." because the signal is defined as (3 downto
> > > 0).
> > > so.....
>
> > > BEGIN
> > >      IF ( rising_edge( CLK_16_6MHZ ) ) THEN
> > >           IF ( RESET_COUNT =3D "1111" ) THEN
> > >                RESET_COUNT                <=3D (others =3D> '0');  --=
 ALL
> > > bits to '0'
> > >                UART_RESET_BUFFER   <=3D '0';
> > >           ELSE
> > >                RESET_COUNT                <=3D RESET_COUNT + 1 ;
> > >                UART_RESET_BUFFER   <=3D '1';
> > >           END IF;
> > >      END IF;
> > > --------------------
> > > HTH
> > > -Dave Pollum
>
> > well certainly:
>
> > ~          IF ( RESET_COUNT( 3 DOWNTO 0 ) =3D "1111" ) THEN
> >  ~              RESET_COUNT( 3 DOWNTO 0 ) <=3D "1111";
>
> > makes no sense.  and 'something' bad happens when the 16th character
> > is in the buffer, so this is definitely a near hit at least. lets see
> > how
> > reset_count, uart_reset_buffer are used...
>
> Ok this is a fking mess.
>
> what was done here was this, the "program" starts with
> uart_reset_buffer
> and uart_reset_next high, and the p5 process counts for 16  clock
> pulses
> to allow the system to startup.  on the 16th pulse (=3D'1111')
> uart_reset_buffer
> goes low, and as a result of the D-FF that is made up on P6,
> uart_reset_next
> waits one clock pulse to go low.  So for 1 and only 1 clock pulse,
>
>           IF ( ( UART_RESET_BUFFER =3D '0' ) AND
>                ( UART_RESET_NEXT   =3D '1' )  )  THEN
>
> is true. This is the trigger for the "hello world" message.
>
> Now I imagine there *must* be a better way to do this, and Jonathan B.
> has
> already pointed out  that his section of code is, in technical terms,
> higgley-piggley,
> but it is not causing my current flub.

I still don't get it.

Here's the simulation of the 16 character printout:

http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap13_=
firstislast16.png

everything looks to me ship-shape.

I'm gonna have to compare this simulation to a 15 character one.

anybody see anything?


Article: 137996
Subject: Re: Why the second flip-flop in Virtex-6?
From: "Jan Bruns" <testzugang_janbruns@arcor.de>
Date: Tue, 3 Feb 2009 22:25:48 +0100
Links: << >>  << T >>  << A >>

"Benjamin Couillard":
> On 3 fév, 08:36, "Jan Bruns" <testzugang_janbr...@arcor.de> wrote:

>> Ok, and what's the real difference between virtex6 and spartan6?
>> The availability of TBUFs, again?

>> What I don't get with spartan3 is why they didn't put
>> some MUX logic into the switch matrices. I hate spending
>> much logic (and specially logic-levels!) on really nothing
>> but a bus.

> - Virtex 6 has a different DSP Block (DSP48E), with a 25x18 multiplier
>   instead of a 18x18 multiplier as in the Spartan-6 (DSP48A)
> - Faster transceivers in Virtex-6
> - 36kbit blockram (V6) instead of 18 kbit block ram (S6)
> - System monitor in Virtex-6

> And I suppose that the Virtex-6 will eventually come with PowerPcs
> embedded in them and also they're probably much faster than Spartan-6.

Thanks, but that's not exactly what I meant to ask.
Will that Spartan6 have internal tristatable interconnects,
and/or better capabilites to build large MUXes?

In Spartan3, a usual way to make a 32:1 MUX requires 16 LUT4
(8 Slices, 2 CLBs) + F5MUX + 3 levels of FXMUXes and because
both CLBs won't absorb much of any logic following the mux32,
the result has to be routed far away.

It seems obvious to me that giving the spartan3 CLB additional full mux32
logic wasn't a theoretical problem nor would it blow up required routing
resources (since a CLB already has enough external interconnects), and
the remaining logic would still be theoretically usable without any
external routing blow up (maybe non-registered adders or registered
counters; not sure if these would mean exactly no blowup, but nearly).

Gruss

Jan Bruns






From rgaddi@technologyhighland.com Tue Feb 03 13:43:10 2009
Path: flpi142.ffdc.sbc.com!flph199.ffdc.sbc.com!prodigy.com!flph200.ffdc.sbc.com!prodigy.net!newshub.sdsu.edu!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.lmi.net!news.lmi.net.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 03 Feb 2009 15:43:06 -0600
Date: Tue, 3 Feb 2009 13:43:10 -0800
From: Rob Gaddi <rgaddi@technologyhighland.com>
Newsgroups: comp.arch.fpga
Subject: Re: Why the second flip-flop in Virtex-6?
Message-Id: <20090203134310.31c9f284.rgaddi@technologyhighland.com>
References: <db8ef9a9-f8cb-4f5f-8bec-0a96dac78cc2@p36g2000prp.googlegroups.com>
	<4988485e$0$30227$9b4e6d93@newsspool1.arcor-online.net>
	<3fc47a0f-ef58-44cf-a39d-391b78543eb1@q30g2000vbn.googlegroups.com>
	<4988b65c$0$32678$9b4e6d93@newsspool2.arcor-online.net>
Organization: Highland Technology, Inc.
X-Newsreader: Sylpheed 2.5.0 (GTK+ 2.10.14; i686-pc-mingw32)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Lines: 57
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 66.117.134.49
X-Trace: sv3-BaPjtREZ2LMKZnt2HYJthDSFixSwl1T+vh4F/SZnX0jI/ZcnTRDCIu5FeowHHtrG+PkqIWu0uT6SBtG!yHSn8YN0+kIQNRWzswJG7IuQudYJlQQnSrCPQwyWaBmdSLKJaEKZkL402MPWFlDCoOWzV55a5vLy!JxYgrJFR9FbiZjYMZs0=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.39
Xref: prodigy.net comp.arch.fpga:151112
X-Received-Date: Tue, 03 Feb 2009 16:43:07 EST (flpi142.ffdc.sbc.com)

On Tue, 3 Feb 2009 22:25:48 +0100
"Jan Bruns" <testzugang_janbruns@arcor.de> wrote:

>=20
> "Benjamin Couillard":
> > On 3 f=E9v, 08:36, "Jan Bruns" <testzugang_janbr...@arcor.de> wrote:
>=20
> >> Ok, and what's the real difference between virtex6 and spartan6?
> >> The availability of TBUFs, again?
>=20
> >> What I don't get with spartan3 is why they didn't put
> >> some MUX logic into the switch matrices. I hate spending
> >> much logic (and specially logic-levels!) on really nothing
> >> but a bus.
>=20
> > - Virtex 6 has a different DSP Block (DSP48E), with a 25x18
> > multiplier instead of a 18x18 multiplier as in the Spartan-6
> > (DSP48A)
> > - Faster transceivers in Virtex-6
> > - 36kbit blockram (V6) instead of 18 kbit block ram (S6)
> > - System monitor in Virtex-6
>=20
> > And I suppose that the Virtex-6 will eventually come with PowerPcs
> > embedded in them and also they're probably much faster than
> > Spartan-6.
>=20
> Thanks, but that's not exactly what I meant to ask.
> Will that Spartan6 have internal tristatable interconnects,
> and/or better capabilites to build large MUXes?
>=20
> In Spartan3, a usual way to make a 32:1 MUX requires 16 LUT4
> (8 Slices, 2 CLBs) + F5MUX + 3 levels of FXMUXes and because
> both CLBs won't absorb much of any logic following the mux32,
> the result has to be routed far away.
>=20
> It seems obvious to me that giving the spartan3 CLB additional full
> mux32 logic wasn't a theoretical problem nor would it blow up
> required routing resources (since a CLB already has enough external
> interconnects), and the remaining logic would still be theoretically
> usable without any external routing blow up (maybe non-registered
> adders or registered counters; not sure if these would mean exactly
> no blowup, but nearly).
>=20
> Gruss
>=20
> Jan Bruns
>=20

I'm guessing that wide multiplexing was one of the major things driving
the move from LUT4s to LUT6s in the V5/V6/S6.  A LUT4 can only implement
a 2:1 +en mux, whereas the LUT6 means that your basic element can be a
4:1. So unless they've dumbed down the FiMUX logic, that means you get
a 32:1 at the F7MUX in one CLB, and a max 64:1 mux at the F8 mux.

--=20
Rob Gaddi, Highland Technology
Email address is currently out of order

Article: 137997
Subject: Re: rs232 uart: testbench vs real world, and the missing first letter.
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Tue, 03 Feb 2009 21:45:00 +0000
Links: << >>  << T >>  << A >>
On Tue, 3 Feb 2009 13:21:25 -0800 (PST), jleslie48 wrote:

>Here's the simulation of the 16 character printout:
>
>http://jleslie48.com/fpga_uartjl_01/11jlmod/ccuart01/screencap/screencap13_firstislast16.png
>
>everything looks to me ship-shape.
>
>I'm gonna have to compare this simulation to a 15 character one.
>
>anybody see anything?

Yes.

Jon, how do I put this politely....

(1) you're not listening;
(2) your debugging technique leaves something to be desired.

I asked you whether you were leaving enough time for the serial
line to settle at its idle condition before the first character
goes out.  You haven't answered, but the answer, very obviously, 
ia "no, you're not".  Your serial line idles for only a few
hundred nanoseconds before the first start bit goes out.
Depending on what the FPGA was doing during configuration,
that might or might not work downstream.  It's hopeless.

So your design is immediately broken.  If it's broken, then
small differences between two forms of brokenness will mask
the real trouble.  Insisting on fixing one minor issue when
so much else is so broken is just a recipe for wasting time.

PLEASE, PLEASE fix the dreadful mess that is your data 
generator. Only when you have something whose behaviour 
is predictable and controllable can you hope to debug any 
real problems.

I sent you a private email suggesting ways you might 
be able to get some useful support.  It may have fallen
into your spamtrap, but whatever, I didn't get a response.
Several of us have seen that you are going at this in 
a creative and generally intelligent, but badly flawed,
way; so you've had loads of suggestions that a less
thoughtful poster would not have received.  For heaven's
sake take the higher-level advice too: SORT THE MESS OUT.
You've now futzed around for about three quite long days
and you still haven't got UART 101 working reliably.
Surely you're smart enough to see that the right solution
is to start again, properly?

yours somewhat despairingly
-- 
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: 137998
Subject: Re: Why the second flip-flop in Virtex-6?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 3 Feb 2009 21:45:05 +0000 (UTC)
Links: << >>  << T >>  << A >>
Jan Bruns <testzugang_janbruns@arcor.de> wrote:
 
> Thanks, but that's not exactly what I meant to ask.
> Will that Spartan6 have internal tristatable interconnects,

As far as I know, that will never happen again.  It is part
of the scaling laws for MOS circuits that as the circuitry
gets smaller the RC time constant of wires increases.  
R increases faster than C decreases, resulting in slower
circuits.  The fix is to add buffers on longer lines,
but those are directional.

> and/or better capabilites to build large MUXes?

This should be possible.  As far as I know, AND/OR logic,
where the signal and its enable drive an AND gate, then
all the AND outputs drive an OR gate to generate the
result.  That can be distributed back to where it is needed.
 
> In Spartan3, a usual way to make a 32:1 MUX requires 16 LUT4
> (8 Slices, 2 CLBs) + F5MUX + 3 levels of FXMUXes and because
> both CLBs won't absorb much of any logic following the mux32,
> the result has to be routed far away.

Can you replace that with AND/OR logic?  

> It seems obvious to me that giving the spartan3 CLB additional full mux32
> logic wasn't a theoretical problem nor would it blow up required routing
> resources (since a CLB already has enough external interconnects), and
> the remaining logic would still be theoretically usable without any
> external routing blow up (maybe non-registered adders or registered
> counters; not sure if these would mean exactly no blowup, but nearly).

-- glen

Article: 137999
Subject: Re: Why the second flip-flop in Virtex-6?
From: MikeD <mmdst23@gmail.com>
Date: Tue, 3 Feb 2009 15:04:55 -0800 (PST)
Links: << >>  << T >>  << A >>
Does anyone know that the V6 with a hard-core PowerPC is on the
roadmap?

Also, what about rad effects/atmospheric neutrons/SEE?  I wonder if
they've stuck this in a neutron beam yet.  (I work in avionics so this
actually is a concern, but from where devices are trending pretty soon
it'll be everyones problem).



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