Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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.comArticle: 137976
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, SteveArticle: 137977
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
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. ThanksArticle: 137979
"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 BrunsArticle: 137980
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: 137981On 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
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, rudiArticle: 137983
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? -- ThomasArticle: 137984
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
>> >> 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, KrisArticle: 137986
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: 137987Jan 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. -- glenArticle: 137988
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 BryanArticle: 137989
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
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: 137991On 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
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
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: 137994On 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
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
"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 orderArticle: 137997
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
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). -- glenArticle: 137999
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:
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