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
james <george@washington.edu> writes: > I have working knowledge of some so called "free" software. The likes > of PCB123 and ExpressPCB are good for hobbyist who need only one or Ah, the likes of "free as in beer" software. No, I wasn't referring to teaser copies of proprietary commercial software with vendor lock-in. I was referring to "free as in speech" software. > two boards that are two layers and small. Also if they don't care for > soldermask and silkscreen. PCB supports huge boards, soldermask, silkscreen, many layers, etc. No vendor lock-in, sources available, no artificial limits, etc. That's the kind of "free" I was referring to - freedom to do what you want/need with it. It *happens* to cost $0, but that's just a bonus ;-) > They are in truth not free. Agreed. > As for Linux based software, I have no knowledge of and therefore > refused to comment on them as I do not run Linux. Geda+pcb runs on Mac and Windows as well. Kicad runs on Windows. So, the fact that you don't run Linux is no excuse - go try them on Windows :-)Article: 137751
So how big would a 16-bit full adder be, when built with your logic? Marc Reinig UCO Lick Laboratory for Adaptive Optics <iajzenszmi@gmail.com> wrote in message news:76db8b25-b084-4900-a31a-aa06a4e1830f@r37g2000prr.googlegroups.com... > > According to the following, optical processors which can replace, and > are much faster than, electronic digital processors have been devised > and are production ready. I encourage all the stakeholders in this > project to expedite its licensing and production so that we > can all benefit from high performance computing in the form of optical > processors. I would like to have an optical processor in my next > desktops, notebooks hand held computers and consumer electronics, > including children's toys. Even future One Laptop Per Child and > Classmate machines could incorporate optical processors. Please refer > to > > Y. A. Zaghloul and A. R. M. Zaghloul, "Complete all-optical processing > polarization-based binary logic gates and optical processors," Opt. > Express 14, 9879-9895 (2006) > http://www.opticsinfobase.org/oe/abstract.cfm?URI=oe-14-21-9879Article: 137752
On Wed, 28 Jan 2009 04:17:42 -0800 (PST), Antti <Antti.Lukats@googlemail.com> wrote: >On Jan 23, 11:24 am, Antti <Antti.Luk...@googlemail.com> wrote: >> it seems that first references to the upcoming Spartan family are in >> the wild already >it seems that printed version of EE Times has already Virtex-6 >Spartan-6 >advertizments in it. can not verify as do not have yet a print copy > >the target url should be > >www.xilinx.com/6 > >so we should probably see there something pretty soon >as Xilinx can not delay the RP announcement any more >long when the print ads are alreayd running "Everything Changes February 2, 2009 Sign up and be the first to know more about Virtex®-6 and Spartan®-6 FPGA Families." Interesting, the Submit button appears broken, but if you edit "testlinx.com" to "Xilinx.com", the registration may have worked. Not quite ready to go live then... - BrianArticle: 137753
"Rob Gaddi":
> Interestingly enough, sometimes even low-leveling the code doesn't
> help. Now that it's become a matter of personal vendetta, I'm a little
> mortified to find out that not even this renders using the carry-out.
I think this is caused by relatively expensive carry-enter and
carry leave routing. It's similar to 2 levels of LUT-logic,
even for short chains.
In the example below, xst assumes max clk1 to be 166 MHz,
whereas clk2 may be 227 MHz. The second version only connects
the adder's outputs to their correspondig slice FF, which are
set/reset some short routing delay after clk.
Reinventing this principle for clk1 would mean to route the
MSB of timer1 out of the slice, adding the just mentioned
routing delay to the clk period (at least from the view of
xst, as it seems).
Gruss
Jan bruns
module test(clk1,clk2,o1,o2);
input clk1;
input clk2;
output o1;
output o2;
reg o1;
reg o2;
parameter p1 = 8'd125;
parameter p2 = 8'd124;
reg [7:0] timer1;
reg [7:0] timer2;
wire [7:0] w1;
wire [7:0] w2;
wire [7:0] w2b;
assign w1 = timer1 - 1'd1;
assign w2 = timer2 - 1'd1;
assign w2b = (timer2 == 8'd0);
always @(posedge clk1)
begin
if (w1[7]) begin
o1 = ~o1;
timer1 = p1;
end else begin
timer1 = w1;
end
end
always @(posedge clk2)
begin
o2 = o2 ^ w2b; // 2 LUT-levels, no carry-logic
if (timer2[7]) begin
timer2 = p2;
end else begin
timer2 = w2; // carry-logic limits clk2 period, according to xst
end
end
endmodule
Article: 137754nnadal@terra.es wrote: > > INCREDIBLE!! > the problem was originated by the PCB. There was some resistance or > short circuit in the bus lines wich hangued the cpu and possibly > destroyed the XCS05. > With a 5V supply between the line and GND we eliminated the shorts but > appeared after few minutes. We try to measure the resistance of the > lines with a tester and found to be lower and lower, accelerating the > decrease if we heated the PCB. Anybody knows the explanation of that ? > thank you ¿Was the PCB designed by rogue clowns? ¿For great justice? Check the eel capacity of your hovercraft.Article: 137755
On Wed, 28 Jan 2009 11:56:48 -0800 (PST), jleslie48
<jon@jonathanleslie.com> wrote:
>Ok,
>
>continuing with the RS232 and Ricks pseudo code for sending out a 16
>character message:
[better code...]
>Well you guys beat it into my head enough times, and instantly
>realized that and I had
>two wires hooked up to TX_DATA_IN that could both send in signals at
>the same time, and
>that would be a no-no. That is when I added the "init_done" boolean
>both here and in the
>regular transmission producer,
Didn't you still have similar messages?
Both processes still have drivers connected to TX_DATA_IN...
You have started to arbitrate between them, but they are both still
driving...
unless you turn them off
> if ( init_done = '1') then
> TX_DATA_IN <= RX_DATA_OUT;
else
TX_DATA_IN <= (others -> 'Z');
> end if;
(and likewise in the other process. If you don't know what 'Z' means,
look up "Tristate logic")
or bring them both out on DIFFERENT signals
TX_DATA_1 <= RX_DATA_OUT;
and switch between them in a third process
(can be purely combinational, as here - it's just a multiplexer)
TX_DATA_IN <= TX_DATA_1 when init_done = '1' else
-- other data source when other condition else
TX_DATA_2;
or combine both processes into one...
NOTE - the first approach isn't actually supported in modern FPGAs.
But you can safely use it - the tools do a good job of transforming it
into the equivalent second approach.
>So, taking the advise I was given here, its time to testbench this
>puppy and see what all my system_startup, init_done, etc are doing.
>Lets see if I can make up a good testbench to this thing
Testbench is well worth doing...
also consider bringing out "init_done< to an external pin - preferably
with a LED on it...
- Brian
Article: 137756On Wed, 28 Jan 2009 13:26:20 -0800 (PST), jleslie48 <jon@jonathanleslie.com> wrote: >I switch 'sources for' from implementation to 'behavioral >simulation' ... >Project Navigator will create a new skeleton source with the following >spec: >Add to Project: Yes >Source Directory: C:\jon >\fpga_uarted_01\2009_01_26\LOKI_New_H_Project_VHDL\Code_Versions\10 - >New_Xilinx_Wrap_Data\LOKI_Top >Source Type: VHDL Test Bench >Source Name: abcd.vhd > >Association: LOKI_TOP all that looks OK and you FOUND the simulator page (took me a while!). Which sim do you have? ISE sim or Modelsim? ... but the question is, when >I click finish, what happens in the console window at the bottom? I see the UnitUnderTest being compiled so that the wizard knows how to wire it up for testing. Is that compilation failing? Might explain the problem. Or, if the wizard won't play, just "add copy of source" a testbench from one of the example projects into your project and edit it to suit. - Brian (LOKI? He's our cat!)Article: 137757
Antti wrote: >> it seems that printed version of EE Times has already Virtex-6 >> Spartan-6 advertizments in it. can not verify as do not have yet a >> print copy Online version of EE Times has the advertizement. Page 20 of the pdf.Article: 137758
On 2009-01-29, Brian Drummond <brian_drummond@btconnect.com> wrote:
> NOTE - the first approach isn't actually supported in modern FPGAs.
> But you can safely use it - the tools do a good job of transforming it
> into the equivalent second approach.
A word of warning regarding tristates (If you already know about how
tristates can cause simulation/synthesis mismatch you can stop reading
now.) Consider the following VHDL code:
library ieee;
use ieee.std_logic_1164.all;
entity foo is
port (
foo1 : in std_logic;
foo2 : in std_logic;
sel1 : in std_logic;
sel2 : in std_logic;
o1 : out std_logic;
o2 : out std_logic
);
end foo;
architecture test of foo is
signal o1_int : std_logic;
signal o2_int : std_logic;
begin -- test
o1 <= o1_int;
o2 <= o2_int;
o1_int <= foo1 when sel1 = '1' else 'Z';
o1_int <= foo2 when sel2 = '1' else 'Z';
process (o1_int)
begin -- process
o2_int <= '1';
if o1_int = '1' then
o2_int <= '0';
end if;
end process;
end test;
When you simulate this o2_int will be set to 1 if o1_int is '0' or 'Z'.
(or 'X' for that matter).
But when you synthesize this things are different:
=========================================================================
* Low Level Synthesis *
=========================================================================
WARNING:Xst:2041 - Unit foo: 1 internal tristate is replaced by logic (pull-up yes): N5.
WARNING:Xst:2039 - Unit foo: 1 multi-source signal is replaced by logic (pull-up yes): o1_MLTSRCEDGE.
This means that 'Z' will correspond to a '1' in the FPGA. Which means that
you will not get the same behavior in simulation as in hardware. (But don't
depend on 'Z' being 1 either, depending on the synthesis tool it could be 0
as well, or don't care for that matter I guess.)
If you use tristates correctly it is not a problem, but you need to be aware
about this situation. Therefore, we don't recommend our students to use
tristates internally.
/Andreas
Article: 137759On Jan 28, 5:30 pm, DJ Delorie <d...@delorie.com> wrote: > james <geo...@washington.edu> writes: > > > As for Linux based software, I have no knowledge of and therefore > > refused to comment on them as I do not run Linux. > > Geda+pcb runs on Mac and Windows as well. Kicad runs on Windows. So, > the fact that you don't run Linux is no excuse - go try them on > Windows :-) There is more than Linux oriented open source software. Even though these packages may run under Windows, that is not their primary domain. FreePCB is a Windows program that works very well. I guess it is just not that well know because when ever I mention it in a discussion like this it seems to be ignored. I suggest that you take a look. It is a pretty good program and has an autorouter. RickArticle: 137760
On Jan 28, 1:45=A0pm, Rob Gaddi <rga...@technologyhighland.com> wrote: > On Wed, 28 Jan 2009 00:41:42 -0800 (PST) > > > > rickman <gnu...@gmail.com> wrote: > > On Jan 27, 9:50 pm, General Schvantzkoph <schvantzk...@yahoo.com> > > wrote: > > > > > -------------------------------------------------------------------= --- > > > > > MAKE_DC_DC: process(clk) > > > > > variable toggle =A0 =A0 : std_logic :=3D '0'; > > > > > constant TICKS_CYC =A0: integer :=3D 32_000_000 / 128_000; constant > > > > TICKS_HALF : integer :=3D TICKS_CYC / 2; > > > > > variable divider =A0 =A0: integer > > > > =A0 =A0 range 0 to TICKS_HALF-1 :=3D TICKS_HALF-1; > > > > > begin > > > > =A0 =A0 if rising_edge(clk) then > > > > =A0 =A0 =A0 =A0 DCLK =A0 =A0<=3D toggle; > > > > > =A0 =A0 =A0 =A0 if ( (divider - 1) < 0 ) then > > > > =A0 =A0 =A0 =A0 =A0 =A0 divider :=3D (TICKS_HALF-1); > > > > =A0 =A0 =A0 =A0 =A0 =A0 toggle =A0:=3D not toggle; > > > > > =A0 =A0 =A0 =A0 else > > > > =A0 =A0 =A0 =A0 =A0 =A0 divider :=3D divider - 1; > > > > =A0 =A0 =A0 =A0 end if; > > > > =A0 =A0 end if; > > > > end process MAKE_DC_DC; > > > > > -------------------------------------------------------------------= --- > > > > I always add 1 bit to my counters and the use the MSB to do the > > > reset, for example if I wanted to divide by 256 I'd do, > > > > reg [8:0] cntr; > > > > always@(posedge clk) begin > > > if(sync_rst || cntr[8]) begin > > > =A0 cntr <=3D 1; > > > end > > > else begin > > > =A0cntr <=3D cntr + 1; > > > end > > > > This forces the synthesizer to use the sync set/reset inputs and the > > > reset path will only have 1 LUT delay in it. > > > I tend to think in terms of hardware and once I know exactly what I > > want from the hardware, I "describe" this in the HDL. =A0In this case, > > the carry out is not registered, so it can't really be described > > inside the clocked process. =A0I hedge with the word "really" because > > this may be possible with the right coding style using variables. =A0Bu= t > > I prefer not to bother too much with "tricky" coding styles and to use > > templates I have the most confidence in. > > > So I would code the counter logic as combinatorial logic and then > > assign it to a register. =A0Of course I can't say for sure this will > > give you what you want, but I think it has a good chance. > > > constant TICKS_CYC =A0: integer :=3D 32_000_000 / 128_000; > > constant TICKS_HALF : integer :=3D TICKS_CYC / 2; > > > signal downcntr =A0 =A0: integer > > =A0 =A0 range -1 to TICKS_HALF-1 :=3D TICKS_HALF-1; > > signal divider... toggle... togglecntr... > > > MAKE_DC_DC: process(divider, toggle) > > begin > > =A0 if rising_edge(clk) then > > =A0 =A0 =A0 =A0 DCLK =A0 =A0<=3D toggle; > > =A0 =A0 downcntr <=3D divider - 1; > > =A0 =A0 if (downcntr < 0) then > > =A0 =A0 =A0 divider :=3D (TICKS_HALF-1); > > =A0 =A0 =A0 togglecntr :=3D not toggle; > > =A0 =A0 else > > =A0 =A0 =A0 divider :=3D divider - 1; > > =A0 =A0 end if; > > =A0 end if; > > end process MAKE_DC_DC; > > > MAKE_DC_DC: process(clk) > > begin > > =A0 if rising_edge(clk) then > > =A0 =A0 divider :=3D mod(downcntr, TICKS_HALF); > > =A0 =A0 toggle =A0:=3D togglecntr; > > =A0 end if; > > end process MAKE_DC_DC; > > > If this form gives you the carry test that you are looking for, then > > maybe you can combine the two processes into one and get the same > > logic. =A0The trick will be to use variable assignments to set the > > variable and compared to -1 before the final assignment that is > > latched into the register. =A0I haven't tested any of this, so I may be > > all washed up. =A0I don't typically use variables. > > > I'm actually more interested in the fact that you consider > > "spelunking" in the FPGA editor to be "fun"... =A0;^) > > > Rick > > Short of a good spelunk, your two choices in knowing whether your code > rendered out the way you want are a) write the code at such a low > abstraction level that the synthesizer can't help but give you what > you're asking for, or b) decide you just don't care that much. I have not done a design in a while where I cared about the size. The first one I did like that was a Xilinx part before they had decent "spelunking" tools and the last one was the design from h377 where we were pushing both speed and density along with fighting a bug in the tools that under estimated delays on wide fanout signals. The Xilinx design was actually my first using an HDL and was very, very tedious with spelunking a state machine that kept blowing up in size (and so slowed down horribly) because the tools would over specify state detection. I think I counted as many as 13 levels of LUTs. In the end I gave up using a typical CASE based state machine and used concurrent assignments to define each FF in a one-hot FSM. It turns out that is a very good match to a one-hot machine and does not require any "smarts" in the tools. The lesson I learned however, was that if you don't really need to optimize an FPGA design, DON'T! It can be a lot of work and any time the tool has an update or you switch tools, all bets are off and the design may no longer be optimized, rather it can be degenerate. Optimizations involving special features of a line of chips is not at all portable to other brands or possibly other lines in the same brand. When I was working for TRW, a PhD there gave a presentation about optimization. Optimization is expensive in terms of time required to do it, it often places restrictions on use, can make debug more expensive and can make changes more expensive. In each case "expensive" means more time, more risk and more problems. Other than this lesson which may seem obvious, but is actually very useful, I found this particular PhD to be a waste of an education. But I guess if each of us can offer at least one lesson like this, we will be doing pretty well. So if you are worrying about optimization without a specific need, maybe you should just not... > Interestingly enough, sometimes even low-leveling the code doesn't > help. =A0Now that it's become a matter of personal vendetta, I'm a little > mortified to find out that not even this renders using the carry-out. > > ---------------------------------------------------------------------- > > -- Generation of 128 kHz from 32 MHz takes 125 cycles high, 125 low; > -- We'll count 124 downto 0, then repeat. > -- > > subtype t_clk_div is signed(7 downto 0); > constant CLK_DIV_MAX =A0 =A0: t_clk_div :=3D TO_SIGNED(124, t_clk_div'len= gth); > > signal toggle =A0 =A0 =A0 =A0 =A0 : std_logic :=3D '0'; > signal divider =A0 =A0 =A0 =A0 =A0: t_clk_div :=3D CLK_DIV_MAX; > signal next_divider =A0 =A0 : t_clk_div :=3D CLK_DIV_MAX; > > begin > > next_divider <=3D divider-1; > > MAKE_DC_DC: process(clk) > begin > =A0 =A0 if rising_edge(clk) then > =A0 =A0 =A0 =A0 DCLK =A0 =A0<=3D toggle; > > =A0 =A0 =A0 =A0 if ( next_divider(next_divider'high) =3D '1' ) then > =A0 =A0 =A0 =A0 =A0 =A0 divider <=3D CLK_DIV_MAX; > =A0 =A0 =A0 =A0 =A0 =A0 toggle =A0<=3D not toggle; > > =A0 =A0 =A0 =A0 else > =A0 =A0 =A0 =A0 =A0 =A0 divider <=3D next_divider; > > =A0 =A0 =A0 =A0 end if; > =A0 =A0 end if; > end process MAKE_DC_DC; > > end architecture; > > ---------------------------------------------------------------------- Yeah, it can be hard to get a tool to do just what you want. I think if I really cared about this sort of thing, I would ask my FAE or call the hotline. Using the carry out in a Xilinx part does cost one LUT since that is how the carry chain is routed out to the fabric. But that is still cheaper than the n LUTs required to detect the zero state and likely still faster. I would hope that there would be some sample code on the Xilinx web site. Actually, I do care. I am not working on it at the moment, but I have a design I'm doing in the background where an up/down counter carry out is in the critical path. When I get back to that, I'll see what I can find about how to code this. RickArticle: 137761
On Jan 28, 7:28=A0pm, "Jan Bruns" <testzugang_janbr...@arcor.de> wrote: > "Rob Gaddi": > > > Interestingly enough, sometimes even low-leveling the code doesn't > > help. =A0Now that it's become a matter of personal vendetta, I'm a litt= le > > mortified to find out that not even this renders using the carry-out. > > I think this is caused by relatively expensive carry-enter and > carry leave routing. It's similar to 2 levels of LUT-logic, > even for short chains. > > In the example below, xst assumes max clk1 to be 166 MHz, > whereas clk2 may be 227 MHz. The second version only connects > the adder's outputs to their correspondig slice FF, which are > set/reset some short routing delay after clk. > > Reinventing this principle for clk1 would mean to route the > MSB of timer1 out of the slice, adding the just mentioned > routing delay to the clk period (at least from the view of > xst, as it seems). > > Gruss > > Jan bruns > > module test(clk1,clk2,o1,o2); > =A0 input clk1; > =A0 input clk2; > =A0 output o1; > =A0 output o2; > =A0 reg o1; > =A0 reg o2; > > =A0 parameter p1 =3D 8'd125; > =A0 parameter p2 =3D 8'd124; > > =A0 reg [7:0] timer1; > =A0 reg [7:0] timer2; > > =A0 wire [7:0] w1; > =A0 wire [7:0] w2; > =A0 wire [7:0] w2b; > > =A0 assign w1 =3D timer1 - 1'd1; > =A0 assign w2 =3D timer2 - 1'd1; > =A0 assign w2b =3D (timer2 =3D=3D 8'd0); > > =A0 always @(posedge clk1) > =A0 begin > =A0 =A0 if (w1[7]) begin > =A0 =A0 =A0 o1 =3D ~o1; > =A0 =A0 =A0 timer1 =3D p1; > =A0 =A0 end else begin > =A0 =A0 =A0 timer1 =3D w1; > =A0 =A0 end > =A0 end > > =A0 always @(posedge clk2) > =A0 begin > =A0 =A0 o2 =3D o2 ^ w2b; =A0// 2 LUT-levels, no carry-logic > =A0 =A0 if (timer2[7]) begin > =A0 =A0 =A0 timer2 =3D p2; > =A0 =A0 end else begin > =A0 =A0 =A0 timer2 =3D w2; =A0// carry-logic limits clk2 period, accordin= g to xst > =A0 =A0 end > =A0 end > > endmodule I'm curious about this. In this case the carry use cost is the time of the carry chain and one LUT to get the carry out of the chain. There is no carry in so the added delay is only 1 LUT delay, not two. However, there may be an additional LUT delay to get the adder inputs into the carry chain which would make it two LUTs plus the carry chain (although I am pretty sure it doesn't go through the LUT). So the break even point (or better than even) may be 17 bits in the counter. What happens when you use a larger counter? I would try it myself, but I don't have the Xilinx tools installed on this machine yet. RickArticle: 137762
I have to say that I find your learning process to be very
interesting. It has been so long for me that I have forgotten exactly
what it was that I had to learn or unlearn to switch from software to
HDL. I am getting a feel for that again.
On Jan 28, 2:56 pm, jleslie48 <j...@jonathanleslie.com> wrote:
> Ok,
>
> continuing with the RS232 and Ricks pseudo code for sending out a 16
> character message:
> --------------------------------------------------------------------------------
> constant TstData : string(0 to 15) := "Testing 1, 2, 3!";
> signal TxCntr : integer range 0 to 16;
>
> TxNxtData <= TstData (TxCntr);
>
> -- Data source control, provide string data to the UART, repeat every
> 16 chars
> process SelectCntr ( clk, reset ) is
> begin
> if (reset = '1') then
> TxCntr <= 0;
> elsif ( rising_edge (clk) ) then
> if ( TxRdy = '0' ) then
> TxWrite <= '0';
> else
> if ( TxWrite = '0' and TxCntr <> 16 ) then
> TxWrite <= '1';
> TxCntr <= TxCntr + 1;
> end if;
> end if;
> end if;
> end process;
>
> ---------------------------------------------------------------------------------
>
> I cleaned this up a bit, used my variable names, to get a synth to
> work:
> ----------------------------------------------------------------------
>
> function to_slv(c: character) return std_logic_vector is
> begin
> return std_logic_vector(to_unsigned(character'pos(c), 8));
> end;
>
> SIGNAL system_startup : STD_LOGIC := '1';
> SIGNAL txwrite : STD_LOGIC := '1';
> SIGNAL txrdy : STD_LOGIC := '0';
> SIGNAL TxNxtData : STD_LOGIC_VECTOR( 7 downto 0 );
> SIGNAL init_done : STD_LOGIC := '0';
> signal TxCntr : integer range 0 to 17;
>
> constant TstData : string(1 to 16) := "Testing 1, 2, 3!";
>
> TxNxtData <= to_slv(TstData(TxCntr));
>
> -- Initialize01
> --
> -- Lets put out a hello world message once when the system first
> starts up,
> --
> -- system_startup, init_done are flags to start the run and signal th
> end.
> -- txrdy and txwrite, do some ping_pong thing to get the chars out I
> think.
> -- lets see.
> --
> initialize01: process ( CLK_16_6MHZ, system_startup )
> begin
> if (system_startup = '1') then --1{
> TxCntr <= 1;
> system_startup <= '0';
> init_done <= '0';
> TxRdy <= '0';
> elsif ( rising_edge (CLK_16_6MHZ) ) then --1
> if ( TxRdy = '0' ) then --5{
> TxWrite <= '0';
> else
> if ( TxWrite = '0' and TxCntr /= 17 ) then --4{
> TxWrite <= '1';
> TxRdy <= '0';
> TxCntr <= TxCntr + 1;
> if (init_done = '0') then --3{
> TX_DATA_IN <= TxNxtData ;
> end if; --3}
> elsif (TxCntr = 17) then --4
> init_done <= '1';
> end if; --4}
> end if; --5}
> end if; --1}
> end process initialize01 ;
> ----------------------------------------------------------------------
>
> the act of getting through the syntax errors was very useful,
> particularly since
> when I added the >>>TX_DATA_IN <= TxNxtData ;<<< line
> I got 8 errors relating to "multiple line drive" or something to that
> effect.
>
> Well you guys beat it into my head enough times, and instantly
> realized that and I had
> two wires hooked up to TX_DATA_IN that could both send in signals at
> the same time, and
> that would be a no-no. That is when I added the "init_done" boolean
> both here and in the
> regular transmission producer, process p7 which I renamed to the more
> appropriate, uart_echo:
> ________________________
>
> --p7
> uart_echo: PROCESS ( CLK_16_6MHZ, UART_RESET_BUFFER,
> RX_READ_BUFFER_STB, RX_DATA_OUT( 7 DOWNTO 0 ) )
> BEGIN
> IF ( CLK_16_6MHZ = '1' AND CLK_16_6MHZ'EVENT ) THEN
> IF ( UART_RESET_BUFFER = '0' ) THEN
> IF ( RX_READ_BUFFER_STB = '1' ) THEN
> if ( init_done = '1') then
> TX_DATA_IN <= RX_DATA_OUT;
> end if;
> END IF;
> END IF;
> END IF;
> END PROCESS uart_echo;
> __________________________
>
> note the TX_DATA_IN line is now dependent on the init_done flag.
>
> well then after being all proud of my synth coming up clean (well no
> errors, and 23 warnings, I didn't say spotless...) I actually took the
> plunge and loaded up my board and ran it.
>
> Yuck.
>
> no hello world message, and even the uart_echo is now broken.
>
> So, taking the advise I was given here, its time to testbench this
> puppy and see what all my system_startup, init_done, etc are doing.
> Lets see if I can make up a good testbench to this thing,
Yeah, I have no idea why the change you made to add init_done would
have gotten rid of the "multiple line drive" error. If you make an
assignment to a signal within a process, that is defining some sort of
driver on that signal. If you make assignments to the same signal
from two different processes, that puts two drivers on the same signal
and creates a problem.
This is another error of thinking like software rather than hardware.
The fact that the two assignment statements are not made under the
same conditions does not make this work any better. It is
"describing" two registers with their outputs tied together and that
will not work. You need a multiplexer to select either the test data
or the receiver data register. Try replacing the uart_echo process
with a concurrent statement...
TX_DATA_IN <= TxNxtData when (init_done = '0') else RX_DATA_OUT ;
Notice that I also removed the assignment to TX_DATA_IN from the
initialize01 process. That was adding a register to the data path
that is not needed. The character counter, TxCntr, provides a select
value to control a mux on the character array. Actually, this logic
is combined and optimized to produce the TxNxtData without actually
having an array of chars and a mux, but that is not important. The
output of this mux is appropriately timed by the changes in TxCntr so
that it can directly drive the UART Tx input, TX_DATA_IN.
Just as a matter of style, init_done also does not need to be in the
clocked process. Any signal assigned in a clocked process produces a
register. init_done only needs to be the decode of the state of
TxCntr = 17. Or even simpler is to use 0 to 15 on the string constant
and to use 16 as the terminal state which brings me to the use of
integers. Again this is an issue of preference, but you can use
signed or unsigned from the ieee.numeric_std package. These types are
related to slv so that they can convert without a conversion
function. They are arrays, so you can pick out individual bits. I
have all but done away with integers myself. Then picking out the msb
of TxCntr would be init_done <= TxCntr (4); as a concurrent
assignment.
A final thought. The dual assignment to TX_DATA_IN should be
producing an error. It will cause an 'X' to be displayed on that
signal in the simulator... or at least it should. It may be a 'U',
I'm not certain. But it won't work correctly until you change the
code.
If you had to draw a diagram of the registers in this design, would
you be able to do that? If you can do that, you can then use
templates to produce the code to match the register descriptions with
very few errors.
Rick
Article: 137763On 2009-01-29, rickman <gnuarm@gmail.com> wrote: > On Jan 28, 10:13 pm, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote: >> On 2009-01-29, Brian Drummond <brian_drumm...@btconnect.com> wrote: >> >> > NOTE - the first approach isn't actually supported in modern FPGAs. >> > But you can safely use it - the tools do a good job of transforming it >> > into the equivalent second approach. >> >> A word of warning regarding tristates (If you already know about how >> tristates can cause simulation/synthesis mismatch you can stop reading >> now.) Consider the following VHDL code: <snip> > The only time I can think of using a tristate internally in an FPGA is > when very old code is being reused. In that case I would expect the > code to be rewritten to replace the tristate buffers with > multiplexers. Has this come up in your career? Some students I supervised did this and had a very hard time debugging it. They had probably read somewhere that the tools could convert tri-states to regular logic automatically and thought that was pretty neat. But the text that told them that the synthesis tool could do this probably never warned them about simulation/synthesis mismatch. (I could also rant about the FPGA book they had borrowed from the library which had a UART example that had more than one clock IIRC... *GRR*) This is one of the reasons why I always try to warn people about this kind of issue whenever I see someone suggesting that it is ok to use tri-states inside an ASIC or FPGA because the tools can convert it to regular logic. The other reason is the same as the one you just described. It is probably much better to model what you really want rather than modelling something you believe that the synthesis tool will probably be able to translate into the thing you want. /AndreasArticle: 137764
rickman <gnuarm@gmail.com> wrote: (snip) > The lesson I learned however, was that if you don't really need to > optimize an FPGA design, DON'T! It can be a lot of work and any time > the tool has an update or you switch tools, all bets are off and the > design may no longer be optimized, rather it can be degenerate. > Optimizations involving special features of a line of chips is not at > all portable to other brands or possibly other lines in the same > brand. Say you had a design that would use 2000 XC3S1600E devices, all with the same logic (different RAM contents) that you believe should run at 200MHz. The first try reports that it will run at 100MHz. Maybe it is worth a little optimizing. (It should have at most three levels of logic between FFs.) -- glenArticle: 137765
rickman <gnuarm@gmail.com> wrote: (snip) > The Xilinx > design was actually my first using an HDL and was very, very tedious > with spelunking a state machine that kept blowing up in size (and so > slowed down horribly) because the tools would over specify state > detection. I think I counted as many as 13 levels of LUTs. I was recently looking at the opencores.org cpu8080 design, modeled after the intel 8080. This one has a big state machine where each state is a different instruction. I haven't tried it in any of the tools yet, but my guess is that there will be many levels of LUTs in the state machine feedback loop. It does make it easy to follow, see what each instruction does, or add new instructions. > In the > end I gave up using a typical CASE based state machine and used > concurrent assignments to define each FF in a one-hot FSM. It turns > out that is a very good match to a one-hot machine and does not > require any "smarts" in the tools. One I did some years ago with Altera tools, which liked to convert state machines to one-hot form even if you didn't write them that way. I was using the state variable (two bits) from outside. It still generated a one-hot and gave me the low two bits of the state register. It seems that I write my state machines in a way that Altera didn't expect, though they did fix the bug. -- glenArticle: 137766
On 2009-01-29, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > There used to by systems with different transmit/receive speed > (modems with 75 baud one direction, 1200 the other). That would > need separate send/receive clocks. I should perhaps acknowledge that it is non-trivial to write a UART if you don't have a clock which is significantly faster than the baud-rate. But in the case you quote you shouldn't have any problems since 1200 is an even multiple of 75. And if I remember correctly this example created an internal clock which was 16 times faster than the baud rate and then used that clock instead of using only one clock. > >> This is one of the reasons why I always try to warn people about this >> kind of issue whenever I see someone suggesting that it is ok to use >> tri-states inside an ASIC or FPGA because the tools can convert it to >> regular logic. > > or use verilog. You will have the same problem in Verilog: if (testsignal == 1) begin do_something; end do_something will not be run in simulation if testsignal is x or z, but in the hardware it may be activated depending on the synthesis tool. /AndreasArticle: 137767
rickman wrote: > On Jan 28, 5:34 am, Alex Freed <alex_n...@mirrow.com> wrote: >> secure...@gmail.com wrote: >>> Hi Alex, >>>> Even the best autorouters make ugly boards. >>> It seems that all producers of software pcb, pointing to this >>> "Autoroute" are all lies ? >> They are not. Autorouters do automatic routing as advertised. >> The only problem is that the results can not be compared >> with manual routing. Maybe I just don't know how to use them >> right, but nobody I know uses autorouting for serious work. >> Sometimes you can let an autorouter do part of the job. > > I think it is a bit extreme to say that "nobody" uses autorouting for > "serious" work. Autorouting is a very useful tool to get a layout in > a short amount of time. Like any tool, you need to know how and when > to use it best. I can assure you that considering the money spent on > the high end autorouters, that ***somebody*** must be using them for > "serious" work. > > I tried to use an autorouter with one of the open source packages, but > got nowhere with it and rather than spend time trying to figure it > out, I just did the route manually. The other "serious" design I laid > out myself I did by hand because of it was a ***very*** tough board to > design and I didn't expect the tool to be able to complete it at all, > much less give a "good" result. > > Regardless of whether you use an autorouter or do the routing > manually, it is essential to have a set of design rules and to make > sure to correctly set up the software to enforce those rules. > > Rick Just out of curiosity, have you tried either of these: http://www.freestyleteam.com/index.php?topic=topor&lang=en http://www.freerouting.net/ mvh., DavidArticle: 137768
On Jan 28, 10:13=A0pm, Andreas Ehliar <ehliar-nos...@isy.liu.se> wrote: > On 2009-01-29, Brian Drummond <brian_drumm...@btconnect.com> wrote: > > > NOTE - the first approach isn't actually supported in modern FPGAs. > > But you can safely use it - the tools do a good job of transforming it > > into the equivalent second approach. > > A word of warning regarding tristates (If you already know about how > tristates can cause simulation/synthesis mismatch you can stop reading > now.) =A0Consider the following VHDL code: > > library ieee; > use ieee.std_logic_1164.all; > entity foo is > > =A0 port ( > =A0 =A0 foo1 : in =A0std_logic; > =A0 =A0 foo2 : in =A0std_logic; > =A0 =A0 sel1 : in =A0std_logic; > =A0 =A0 sel2 : in =A0std_logic; > =A0 =A0 o1 =A0 : out std_logic; > =A0 =A0 o2 =A0 : out std_logic > =A0 =A0 ); > > end foo; > > architecture test of foo is > =A0 signal o1_int : std_logic; > =A0 signal o2_int : std_logic; > begin =A0-- test > > =A0 o1 <=3D o1_int; > =A0 o2 <=3D o2_int; > > =A0 o1_int <=3D foo1 when sel1 =3D '1' else 'Z'; > =A0 o1_int <=3D foo2 when sel2 =3D '1' else 'Z'; > > =A0 process (o1_int) > =A0 begin =A0-- process > =A0 =A0 o2_int <=3D '1'; > =A0 =A0 if o1_int =3D '1' then > =A0 =A0 =A0 o2_int <=3D '0'; > =A0 =A0 end if; > =A0 end process; > > end test; > > When you simulate this o2_int will be set to 1 if o1_int is '0' or 'Z'. > (or 'X' for that matter). > > But when you synthesize this things are different: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > * =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Low Level Synthesis =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 * > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > WARNING:Xst:2041 - Unit foo: 1 internal tristate is replaced by logic (pu= ll-up yes): N5. > WARNING:Xst:2039 - Unit foo: 1 multi-source signal is replaced by logic (= pull-up yes): o1_MLTSRCEDGE. > > This means that 'Z' will correspond to a '1' in the FPGA. Which means tha= t > you will not get the same behavior in simulation as in hardware. (But don= 't > depend on 'Z' being 1 either, depending on the synthesis tool it could be= 0 > as well, or don't care for that matter I guess.) > > If you use tristates correctly it is not a problem, but you need to be aw= are > about this situation. Therefore, we don't recommend our students to use > tristates internally. Maybe I don't understand the significance of this. Tristates are *not* supported internally in FPGAs. You can use a tristate on an I/O pin, but I don't know of any modern FPGA families that use tristate drivers inside the FPGA. Why would anyone concern themselves with how the simulation and synthesis mismatch when you really shouldn't be using an internal tristate at all??? The only time I can think of using a tristate internally in an FPGA is when very old code is being reused. In that case I would expect the code to be rewritten to replace the tristate buffers with multiplexers. Has this come up in your career? RickArticle: 137769
On Jan 29, 1:58=A0am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On Wed, 28 Jan 2009 04:17:42 -0800 (PST), Antti > > <Antti.Luk...@googlemail.com> wrote: > >On Jan 23, 11:24=A0am, Antti <Antti.Luk...@googlemail.com> wrote: > >> it seems that first references to the upcoming Spartan family are in > >> the wild already > >it seems that printed version of EE Times has already Virtex-6 > >Spartan-6 > >advertizments in it. can not verify as do not have yet a print copy > > >the target url should be > > >www.xilinx.com/6 > > >so we should probably see there something pretty soon > >as Xilinx can not delay the RP announcement any more > >long when the print ads are alreayd running > > "Everything Changes February 2, 2009 > > Sign up and be the first to know more about Virtex=AE-6 and Spartan=AE-6 > FPGA Families." > > Interesting, the Submit button appears broken, but if you edit > "testlinx.com" to "Xilinx.com", the registration may have worked. > Not quite ready to go live then... > > - Brian its not broken, was working now. well will see, do they really say "the Spartan-6 with ARM core will be available on digikey on <insert date here>" or please have patience.. the ES samples of arm enabled S-6 silicon will be shipping to EA customers in year 201x ? but only a few days ;) to know this AnttiArticle: 137770
On Jan 29, 3:34=C2=A0am, David Brown <da...@westcontrol.removethisbit.com> wrote: > rickman wrote: > > On Jan 28, 5:34 am, Alex Freed <alex_n...@mirrow.com> wrote: > >> secure...@gmail.com wrote: > >>> Hi Alex, > >>>> Even the best autorouters make ugly boards. > >>> It seems that all producers of software pcb, pointing to this > >>> "Autoroute" are all lies ? > >> They are not. Autorouters do automatic routing as advertised. > >> The only problem is that the results can not be compared > >> with manual routing. Maybe I just don't know how to use them > >> right, but nobody I know uses autorouting for serious work. > >> Sometimes you can let an autorouter do part of the job. > > > I think it is a bit extreme to say that "nobody" uses autorouting for > > "serious" work. =C2=A0Autorouting is a very useful tool to get a layout= in > > a short amount of time. =C2=A0Like any tool, you need to know how and w= hen > > to use it best. =C2=A0I can assure you that considering the money spent= on > > the high end autorouters, that ***somebody*** must be using them for > > "serious" work. > > > I tried to use an autorouter with one of the open source packages, but > > got nowhere with it and rather than spend time trying to figure it > > out, I just did the route manually. =C2=A0The other "serious" design I = laid > > out myself I did by hand because of it was a ***very*** tough board to > > design and I didn't expect the tool to be able to complete it at all, > > much less give a "good" result. > > > Regardless of whether you use an autorouter or do the routing > > manually, it is essential to have a set of design rules and to make > > sure to correctly set up the software to enforce those rules. > > > Rick > > Just out of curiosity, have you tried either of these: > > http://www.freestyleteam.com/index.php?topic=3Dtopor=E2=8C=A9=3Denhttp://= www.freerouting.net/ I'm not a PCB layout guy. I have only done two boards. One was small and very dense, so I am pretty sure an autorouter would not have done a good job. Worse, if it wouldn't complete, then I would have had to route it by hand myself to make sure. The other board might have been doable by autorouter, but I couldn't get it to work, so rather than spend time with a tool I didn't know much about, I just routed it by hand. My next board may be my second attempt to autoroute, but it will require a good set of docs that make the tool easy to use. RickArticle: 137771
On Wed, 28 Jan 2009 11:56:48 -0800 (PST), jleslie48 wrote:
>constant TstData : string(0 to 15) := "Testing 1, 2, 3!";
A VHDL language-lawyer thing that will probably hit you
as soon as you try to use a professional-grade simulator:
The built-in data type "string" is defined as
type string is array (positive range <>) of character;
and "positive" is
subtype positive is integer range 1 to INTEGER'HIGH;
So a string indexed from 0 is technically illegal. I'm
a little surprised that the tools you've already tried
allowed you to get away with it, but there's no doubt that
synthesis tools (and particularly FPGA vendor tools) are
a tad sloppy about things like that.
You can write
constant TstData: string (1 to 16) := ...
or even (eccentrically)
... string (16 downto 1) ...
but you must not include 0 in the subscript range.
Note, too, that you don't need to specify the
subscript range for an array constant:
constant TstData: string := "Testing";
will automatically give TstData the range (1 to 7).
You can then make your counter track the size
of the constant automatically like this:
signal StrPtr: integer range TstData'range;
...
if reset = '1' then
StrPtr <= TstData'low;
elsif rising_edge(clock) then
if (it's time to increment the pointer) then
if StrPtr = TstData'high then
StrPtr <= TstData'low;
else
StrPtr <= StrPtr + 1;
end if;
...
--
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: 137772Andreas Ehliar <ehliar-nospam@isy.liu.se> wrote: > This means that 'Z' will correspond to a '1' in the FPGA. Which means that > you will not get the same behavior in simulation as in hardware. (But don't > depend on 'Z' being 1 either, depending on the synthesis tool it could be 0 > as well, or don't care for that matter I guess.) Early FPGAs had internal tristate buffers. I believe with keepers on them such that they stay at the last level. Those don't scale well, though, so now the synthesis tools generate something else. If it is AND/OR logic then Z will come out as 0. FPGA tools like to move inverters around, so 1 is probably about as likely. > If you use tristates correctly it is not a problem, but you need to > be aware about this situation. Therefore, we don't recommend > our students to use tristates internally. You might as well generate AND/OR logic yourself. Though in converting an existing design (say a box full of 7400 series logic) it might be more consistent to keep them. -- glenArticle: 137773
Andreas Ehliar <ehliar-nospam@isy.liu.se> wrote: (snip) >>> A word of warning regarding tristates (If you already know about how >>> tristates can cause simulation/synthesis mismatch you can stop reading >>> now.) ?Consider the following VHDL code: (previous snip of verilog code) I believe verilog doesn't have this problem. You will get X if you use Z with most operators. && and || will not give X if the other operand is 0 or 1 respectively, but that should also synthesize correctly. > <snip> >> The only time I can think of using a tristate internally in an FPGA is >> when very old code is being reused. In that case I would expect the >> code to be rewritten to replace the tristate buffers with >> multiplexers. Has this come up in your career? Multiplexers, or AND/OR logic. But if the logic is easier to describe in tristate form, that should be fine. > Some students I supervised did this and had a very hard time debugging it. > They had probably read somewhere that the tools could convert tri-states > to regular logic automatically and thought that was pretty neat. But the > text that told them that the synthesis tool could do this probably never > warned them about simulation/synthesis mismatch. (I could also rant about > the FPGA book they had borrowed from the library which had a UART example > that had more than one clock IIRC... *GRR*) There used to by systems with different transmit/receive speed (modems with 75 baud one direction, 1200 the other). That would need separate send/receive clocks. > This is one of the reasons why I always try to warn people about this > kind of issue whenever I see someone suggesting that it is ok to use > tri-states inside an ASIC or FPGA because the tools can convert it to > regular logic. or use verilog. > The other reason is the same as the one you just described. It is > probably much better to model what you really want rather than modelling > something you believe that the synthesis tool will probably be able to > translate into the thing you want. -- glenArticle: 137774
"rickman": > I'm curious about this. In this case the carry use cost is the time > of the carry chain and one LUT to get the carry out of the chain. > There is no carry in so the added delay is only 1 LUT delay, not two. > However, there may be an additional LUT delay to get the adder inputs > into the carry chain which would make it two LUTs plus the carry chain > (although I am pretty sure it doesn't go through the LUT). So the > break even point (or better than even) may be 17 bits in the counter. > What happens when you use a larger counter? I would try it myself, > but I don't have the Xilinx tools installed on this machine yet. I've tried an 28 Bit counter. The clk2-Version scaled as expected: Just a longer carry chain, and 3 instead of 2 LUT-Levels in the XOR-Path. The clk1-Version however looks really weird: It now uses two carry chains. One to detect the carry, and the other to do the actual decrement. Probably because both chains contribute to the one FF array, this version seems to be slower (current webpack xst, Spartan3). Gruss Jan Bruns
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