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
On May 25, 7:14=A0pm, sbatt...@yahoo.co.jp wrote: > On May 26, 3:58=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > > > > On May 25, 9:16=A0am, Peter Alfke <al...@sbcglobal.net> wrote: > > > > On May 25, 2:11=A0am, sbatt...@yahoo.co.jp wrote: > > > > > Hi guys, > > > > At the moment I'm waiting to find out whether I will be using Xilin= x > > > > or Actel for my project, and so I'm putting it together for both ju= st > > > > in case. > > > > > In the Actel IP cores, there is an array adder which allows a good > > > > number of inputs, and there's some optional pipelining. I figure it= 's > > > > sufficient to just drop this in and wire up as many inputs as I nee= d. > > > > > Xilinx IP cores seem to have only 2-input adders, and I guess these > > > > are probably inferred by XST with the + operator anyway, so I don't > > > > want to bother with the IP core gen unless there's some reason why = I > > > > should. > > > > Supposing I want: > > > > > Result <=3D A + B + C + D + E; > > > > Note, I used only five inputs in my example for brevity, I will hav= e > > > > more like 25 in my actual system. > > > > > (looking in the XST manual, I can either pad the inputs with leadin= g > > > > zeros or convert to integer and back to std_logic_vector to get car= ry > > > > bits to fill my wider result) > > > > > At the end of the day, when I synthesize this, would there be any > > > > difference between coding it in stages (adding pairs of two togethe= r, > > > > then adding their sums together, and so on until all are added up) = and > > > > just putting A+B+C+D+E in one statement? > > > > All I can think of is that (depending how well conversions to/from > > > > integer are optimized in XST) I might save a few bits of space in t= he > > > > first stages. > > > > Using the bit padding method, I suppose that all of the adders in t= he > > > > first stages would wind up unnecessarily being the same width as th= e > > > > result. > > > > > Anyway, I'm just curious how this will end up working... any insigh= t > > > > appreciated! > > > > > Steve > > > > If I understand you right, you have 25 parallel inputs, each sending > > > you bit-serial data. > > > You need to convert the 25 inputs into one 6-bit binary word, and the= n > > > accumulate these words with increasing (or decreasing) binary weight. > > > > Conversion of 25 lines to 6 bits can be done in many ways, including > > > sequential scanning or shifting, which requires a faster clock of > > > > 1.5 MHz. > > > But here is an unconventional and simpler way: > > > Use 13 inputs as address to one port of a BlockRAM with 4 parallel > > > outputs =A0(8K x 4) > > > Use the remaining 12 inputs as address to the other port of the same > > > BlockRAM. > > > Store the conversion of (# of active inputs to a binary value) in the > > > BlockRAM. > > > > Add the two 4 bit binary words together to form a 5-bit word that > > > always represents the number of active inputs. > > > Then feed this 5-bit value into a 13-bit accumulator, where you shift > > > the content after each clock tick. > > > > This costs you one BlockRAM plus three or four CLBs in Xilinx > > > nomenclature, a tiny portion of the smallest Spartan or Virtex device= , > > > and it could be run a few thousand times faster than you need. > > > If you have more than 26 inputs, just add another BlockRAM for a tota= l > > > of up to 52 inputs, and extend the adder and accumulator by one bit. > > > (Yes, I know in Spartan you are limited to 12 address inputs, (4K x > > > 4), but you can add the remaining bit outside...) > > > > Peter Alfke, from home.- Hide quoted text - > > > > - Show quoted text - > > > Hi Steve, > > 1. Set up a 16*8 FIFO; > > 2. Each of 25 data sources is first registered in its 8-bit register > > with valid bit when data bits are full from its serial data source; > > 3. When valid =3D '1', push the data into FIFO and clear the valid bit; > > 4. Set up a 13-bit register with initialized 0 data when a new > > calculation starts; > > 5. When FIFO is not empty, add 13-bit register with high 5-bit being > > '0' and low 8-bit from FIFO output. > > > There is no need for 25 data sources. > > > Weng > > Hi Weng, > > I'm sorry I didn't explain in full what I am doing. There is only one > serial source feeding a string of delay lines, and at the end of the > delay lines is a 5x5 array of 8-bit registers whose sum I need to > calculate. Each time the serial source gets a byte in, everything in > the delay lines and 5x5 array gets shifted, and I have a new sum to > calculate (this happens once every ms or so, though, so I'm not really > worried about carry propagation). > So in this case, I don't think a FIFO would help any? > > As far as I can see, as noted in my reply to Andy's post, my options > are (a slightly modified version of) his suggested accumulator > solution, or feeding my 25 inputs into a tree of adders. There could > be some other clever solution though? > > I was originally just wondering if XST would generate such a tree with > 25 operands in a sum statement, or if I would have to build the tree > myself in a few statements. > The Actel array adder IP apparently uses the DADDA algorithm to handle > multiple inputs, but I haven't seen anything in the XST docs about > multiple-operand addition.- Hide quoted text - > > - Show quoted text - "Each time the serial source gets a byte in, everything in the delay lines and 5x5 array gets shifted, and I have a new sum to calculate", OK, there is no FIFO needed. Every time you get a byte from the serial input, a 13-bit adder is used to add the data with high 5-bit '0' on the same clock when the byte is being shifted. WengArticle: 140801
"David Antliff" <david.antliff@gmail.com> wrote in message news:ece3bfd9-eb3f-495f-8371-722e105e915d@b7g2000pre.googlegroups.com... > One option for doing this would be to have the make file call a Project > Navigator Tcl script (using xtclsh). This script would create a > fresh .ise file every run, and could also be used to run from the GUI. I > posted a script for this sometime ago, and will update it if desired. This sounds useful - can you direct me towards a recent version of this please? ========= I just use the <project>.xise file. Starting the gui with just that file in the project directory produces all the other files.Article: 140802
MM <mbmsv@yahoo.com> wrote: > "Symon" <symon_brewer@hotmail.com> wrote in message > news:gvf2nc$r78$1@news.eternal-september.org... >> MM wrote: >>>> 3. Why DSP and Memory are rectangular in shape ? >>> >>> Do you mean why they are not round? >>> >>> >> No, why are they rectangular? Do you know? > > Poincare‘s conjecture says that no matter what it looks like, it's > a sphere. That's a load of balls!Article: 140803
On May 26, 5:58=A0am, Andy <jonesa...@comcast.net> wrote:
> Here ya go...
>
> State2 : process(CLK)
> begin
> =A0 =A0if rising_edge(CLK) then
> =A0 =A0 =A0 if SINI =3D '1' then
> =A0 =A0 =A0 =A0 State2 <=3D Idle_S;
> =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 case State2 is
> =A0 =A0 =A0 =A0 when Idle_S =3D>
> =A0 =A0 =A0 =A0 =A0 if A1 =3D '1' then
> =A0 =A0 =A0 =A0 =A0 =A0 State2 <=3D X_S;
> =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 =A0 when X_S =3D>
> =A0 =A0 =A0 =A0 =A0 if A2 =3D '1' then
> =A0 =A0 =A0 =A0 =A0 =A0 State2 <=3D Idle_S;
> =A0 =A0 =A0 =A0 =A0 end if;
> =A0 =A0 =A0 =A0 end case;
> =A0 =A0 =A0 end if; -- sini
> =A0 =A0end if; -- clk
> end process;
>
> Unless you know that SINI is initially asserted (to initialize the
> state machine), you will need a reset for the state machine too.
>
> Andy
Hi Andy and Brian,
1. Good point: use one process state machine.
2. How do you handle turn-on signals in a state machine?
State2_B : process(State2, A1, A2)
begin
Turn_On <=3D '0';
case State2 is
when Idle_S =3D>
if A1 =3D '1' then
Turn_On <=3D '1';
State2_NS <=3D X_S;
-- else <-- key difference
-- State2_NS <=3D Idle_S;
end if;
when X_S =3D>
if A2 =3D '1' then
State2_NS <=3D Idle_S;
else
State2_NS <=3D X_S;
end if;
end case;
end process;
3. I don't like one process state machine writing type and Xilinx and
Altera all recommend using 2 process method. I have a state machine
that has 3000 lines and 30 turn-on signals.
One process method is hard to handle my situation.
4. I say VHDL synthesizer should be SMARTER to avoid generating
transparent latch in the exact my situations:
Locally State2_NS is described as transparent latches, but globally,
they are only used in one statement: State2 <=3D State2_NS; or they are
assigned to registers: State2 which is the case signal in the case
process so that
generating transparent latches for State2_NS is OVER-REACTING and
State2_NS should be generated as a combinational logic !!!
That is what I want to say and highlight !!!
Global optimization rule for VHDL synthesizers: if a type signal (as
State2_NS) is specified in a case process (case process is a process
that contains only one case statement as State2_B shows) as a latch
type, and it is only used to be assigned to the case signal in the
case process, the latch signal can be reduced to combinational logic
without any harm, because the case register keeps the data unchanged
for the latch signal.
Weng
Article: 140804On May 26, 5:26=A0pm, Uwe Bonnes <b...@elektron.ikp.physik.tu- darmstadt.de> wrote: > Sandro <sdro...@netscape.net> wrote: > > Uwe, > > maybe you already know it... else you can be interessed > > in this project (GPL): > > =A0http://www.urjtag.org/ > > They does support a lot of cable and > > EXPERIMENTALLY (they declare to NOT to use it) they can > > do something with xilinx platform cable too (both embedded and > > external)! (below you can find the > > list of cable supported) > > Rudi, > > with 10.x I successfully used > > =A0 =A0http://www.rmdir.de/~michael/xilinx/ > > I didn't try with 11.x (still not downloaded...) > > maybe should you wait the new libusb-driver version ;-) > > xc3sprog takes JEDEC/Bitfile directly, so no need to generate SVF, and a > chance to generated better error feedback. xc3sprog only needs command li= ne > parameters, so it integrated nice into makefiles. Speed may be another > issue. > > Bye > > -- > Uwe Bonnes =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0b...@elektron.ikp.physik.tu-dar= mstadt.de > > Institut fuer Kernphysik =A0Schlossgartenstrasse 9 =A064289 Darmstadt > --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- I think Rudi needs to use Xilinx USB cable with XILINX tools not with 3rd party XXX or 3rd party FX2 firmware AnttiArticle: 140805
On May 25, 12:47=A0am, yuchi...@gmail.com wrote: > Dear all, > I am very interested in the arcchitecture of FPGA of commercial > product. But I have the following questions: > 1. Is that all logic elements in FPGA are rectangular in shape (e.g. > CLB) and why ? > 2. Why DSP/ Memory are arranged in column rather than putting > together? > 3. Why DSP and Memory are rectangular in shape ? > 4. Are there special wire connection between DSP or memory ? e.g. bus > base connection. > > Can expert answer my questions ? > > Thank you very much for your help. > > Best regards, > Yu Hi Yu, The answer doesn't seem to be as simple as people thinks: I have more than once asked myself if there is a better tile shape, but its final decision is based on manufacure experiences, not on guess work. One block is called one tile in the FPGA architecture. FPGA manufacturers usually duplicate many tiles to create a lot versions of products of different sizes. That generates a problem you have asked: what is the best shape one tile should have to make manufacture as simple as possible while keeping no holes among them to maximum the number of products within a fixed one silicon chip? Hexagon is possible, but it would generate more trouble for bus interconnections and it would generate waste materials along chip boundaries. For more information, Xilinx patent: 7274214, "Efficient tile layout for a programmable logic device.pdf" http://www.google.com/patents?id=3DdGeEAAAAEBAJ&dq=3Dpatent:7274214&as_drrb= _ap=3Dq&as_minm_ap=3D0&as_miny_ap=3D&as_maxm_ap=3D0&as_maxy_ap=3D&as_drrb_i= s=3Dq&as_minm_is=3D0&as_miny_is=3D&as_maxm_is=3D0&as_maxy_is=3D I have carefully and thoroughly read the patent, but with purposes different from yours. It is very interesting and instructive. WengArticle: 140806
Hi everybody,
I am trying to drive a LCD display using a CPLD (Digilent board XC2-XL
and a display with the SED1278F chip)
The out come: I have downloaded the code to the board and noting
happened, no display at all.
I have tried the 2 code the one in Xilinx Application note XAPP904 and
the one in Diligent website
Can anyone help here?
Here is the code:
Xilinx Application note XAPP904
Here is 3 vhdl files: top, lcd_module, power_up_module
___________________________________
TOP FILE
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
---- Uncomment the following library declaration if instantiating
---- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity top is
Port ( clk : in std_logic;
ireset : in std_logic;
lcd_db : out std_logic_vector(7 downto 0);
lcd_rs : out std_logic;
lcd_rw : out std_logic;
resetout : out std_logic;
lcd_e : out std_logic);
end top;
architecture Behavioral of top is
component lcd is
Port ( clk : in std_logic;
reset : in std_logic;
DB : in std_logic_vector(7 downto 0);
W : in std_logic;
Ready : inout std_logic;
lcd_rs : out std_logic;
lcd_rw : out std_logic;
lcd_e : out std_logic;
lcd_db : out std_logic_vector(7 downto 0));
end component;
signal ilcd_rs : std_logic;
signal imode : std_logic;
signal sreset : std_logic;
signal lcd_w : std_logic;
signal reset : std_logic;
signal lcd_ready : std_logic;
signal CharBus : std_logic_vector(7 downto 0);
signal count : std_logic_vector(3 downto 0);
signal scalecount : std_logic_vector(23 downto 0);
--
**************************************************************************
-- STATE MACHINE SIGNAL DECLARATION:
type StateType is (
Standby,
WriteCommand,
WriteData,
stop
);
signal CurrentState, NextState : StateType;
--
**************************************************************************
begin
lcd_rs <= ilcd_rs and not imode;
imode <= '1' when (CharBUs(7 downto 4) = 1) else '0';
resetout <= ireset;
reset <= not ireset;
lcd_module: lcd
Port map( clk => clk,
reset => reset,
DB => CharBus,
W => lcd_w,
Ready => lcd_ready,
lcd_rs => ilcd_rs,
lcd_rw => lcd_rw,
lcd_e => lcd_e,
lcd_db => lcd_db);
process(lcd_ready, reset)
begin
if(reset = '1') then
count <= (others=> '0');
elsif(lcd_ready'event and lcd_ready = '1') then
if (count = 13) then
count <= count;
else
count <= count + 1;
end if;
end if;
end process;
process(clk, sreset)
begin
if(sreset = '1') then
scalecount <= (others=> '0');
elsif(clk'event and clk = '1') then
scalecount <= scalecount + 1;
end if;
end process;
COMB: process(CurrentState, lcd_ready, count, scalecount)
begin
case CurrentState is
when Standby =>
if(lcd_ready = '1') then
NextState <= WriteCommand;
else NextState <= Standby;
end if;
when WriteCommand =>
NextState <= WriteData;
when WriteData =>
if(count = 13) then
NextState <= stop;
else NextState <= standby;
end if;
when stop =>
if(scalecount(20) = '1') then
NextState <= standby;
else
NextState <= stop;
end if;
end case;
end process COMB;
SEQ: process(reset, clk)
begin
if(reset = '1') then
CurrentState <= standby;
elsif (clk'event and clk = '1') then
CurrentState <= NextState;
end if;
end process SEQ;
with CurrentState select
lcd_w <= '1' when WriteCommand,
'1' when WriteData,
'0' when Others;
with CurrentState select
sreset <= '0' when Stop,
'1' when Others;
CharBus <=
x"58" when count = 1 else --X
x"49" when count = 2 else --I
x"4C" when count = 3 else --L
x"49" when count = 4 else --I
x"4E" when count = 5 else --N
x"58" when count = 6 else --X
x"20" when count = 7 else --
x"43" when count = 8 else --C
x"50" when count = 9 else --P
x"4C" when count = 10 else --L
x"44" when count = 11 else --D
x"20" when count = 12 else --
x"58" when count = 1 else --X
x"49" when count = 2 else --I
x"4C" when count = 3 else --L
x"49" when count = 4 else --I
x"4E" when count = 5 else --N
x"58" when count = 6 else --X
x"20" when count = 7 else --
x"18";
end Behavioral;
_______________________________________________
lcd_module
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
-- Uncomment the following lines to use the declarations that are
-- provided for instantiating Xilinx primitive components.
--library UNISIM;
--use UNISIM.VComponents.all;
entity lcd is
generic( N: natural := 40000);
Port ( clk : in std_logic;
reset : in std_logic;
DB : in std_logic_vector(7 downto 0);
W : in std_logic;
Ready : inout std_logic;
lcd_rs : out std_logic;
lcd_rw : out std_logic;
lcd_e : out std_logic;
lcd_db : out std_logic_vector(7 downto 0));
end lcd;
architecture Behavioral of lcd is
component power_up is
generic( N: natural);
Port ( clk : in std_logic;
reset : in std_logic;
counter_reset : in std_logic;
data : out std_logic_vector(7 downto 0);
count : out std_logic_vector(15 downto 0);
done : out std_logic
);
end component;
signal data : std_logic_vector(7 downto 0);
signal counter : std_logic_vector(15 downto 0);
signal init_done : std_logic;
signal WriteDataState : std_logic;
signal WriteC0State : std_logic;
signal bitcounter : std_logic_vector(3 downto 0);
signal bitcounter_enable : std_logic;
--
**************************************************************************
-- STATE MACHINE SIGNAL DECLARATION:
type StateType is (
Init,
Standby,
WriteData,
WriteC0 --nineth character
);
signal CurrentState, NextState : StateType;
--
**************************************************************************
begin
power_up_module: power_up
generic map (N)
port map ( clk => clk,
reset => reset,
counter_reset => Ready,
data => data,
count => counter,
done => init_done);
COMB: process(CurrentState, counter, W, init_done,bitcounter)
begin
case CurrentState is
when Init =>
if(init_done = '1') then -- if 16 mS have elapsed,
NextState <= Standby;
else NextState <= Init;
end if;
when Standby =>
if(W = '1') then -- if 16 mS have elapsed,
NextState <= WriteData;
else NextState <= Standby;
end if;
when WriteData =>
if(counter >= N) then -- if 16 mS have elapsed,
if(bitcounter = 15) then
NextState <= WriteC0;
else
NextState <= Standby;
end if;
else NextState <= WriteData;
end if;
when WriteC0 =>
if(counter >= N) then -- if 16 mS have elapsed,
NextState <= Standby;
else NextState <= WriteC0;
end if;
end case;
end process COMB;
SEQ: process(reset, clk)
begin
if(reset = '1') then
CurrentState <= Init;
elsif (clk'event and clk = '1') then
CurrentState <= NextState;
end if;
end process SEQ;
with CurrentState select
Ready <= '1' when Standby,
'0' when Others;
with CurrentState select
WriteDataState <= '1' when WriteData,
'0' when Others;
with CurrentState select
WriteC0State <= '1' when WriteC0,
'0' when Others;
--
**************************************************************************
-- 4 bit counter
--
**************************************************************************
bitcounter_enable <= '1' when ((counter = 5) and (WriteDataState =
'1')) else '0';
process(reset, clk, bitcounter_enable)
begin
if(reset = '1') then
bitcounter <= (others=>'0');
elsif (clk'event and clk = '1') then
if(bitcounter_enable = '1') then
bitcounter <= bitcounter + 1;
end if;
end if;
end process;
--**************************************************************
LCD_DB <= x"C0" when WriteC0State = '1' else
DB when init_done = '1' else
data;
LCD_RS <= '1' when (WriteDataState = '1') else '0';
LCD_RW <= '0'; -- write only
LCD_E <= '1' when (counter = 5) else '0';
end Behavioral;
_______________________________________________
power_up_module
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
-- Uncomment the following lines to use the declarations that are
-- provided for instantiating Xilinx primitive components.
--library UNISIM;
--use UNISIM.VComponents.all;
entity power_up is
generic( N: natural);--:= 40000);
Port ( clk : in std_logic;
reset : in std_logic;
counter_reset : in std_logic;
data : out std_logic_vector(7 downto 0);
count : out std_logic_vector(15 downto 0);
done : out std_logic
);
end power_up;
architecture Behavioral of power_up is
--
**************************************************************************
-- STATE MACHINE SIGNAL DECLARATION:
type StateType is (
PowerUp,
Hex38_1,
Hex38_2,
Hex38_3,
Hex38_4,
Hex07,
Hex0C,
Hex01,
Hex80,
INIT_DONE
);
signal CurrentState, NextState : StateType;
--
**************************************************************************
signal counter : std_logic_vector(15 downto 0);
begin
COMB: process(CurrentState, counter)
begin
case CurrentState is
when PowerUp =>
if(counter >= N) then -- if 16 mS have elapsed,
NextState <= Hex38_1;
else NextState <= PowerUp;
end if;
when Hex38_1 =>
if(counter >= N) then -- if 16 mS have elapsed,
NextState <= Hex38_2;
else NextState <= Hex38_1;
end if;
when Hex38_2 =>
if(counter >= N) then -- if 16 mS have elapsed,
NextState <= Hex38_3;
else NextState <= Hex38_2;
end if;
when Hex38_3 =>
if(counter >= N) then -- if 16 mS have elapsed,
NextState <= Hex38_4;
else NextState <= Hex38_3;
end if;
when Hex38_4 =>
if(counter >= N) then -- if 16 mS have elapsed,
NextState <= Hex07;
else NextState <= Hex38_4;
end if;
when Hex07 =>
if(counter >= N) then -- if 16 mS have elapsed,
NextState <= Hex0C;
else NextState <= Hex07;
end if;
when Hex0C =>
if(counter >= N) then -- if 16 mS have elapsed,
NextState <= Hex01;
else NextState <= Hex0C;
end if;
when Hex01 =>
if(counter >= N) then -- if 16 mS have elapsed,
NextState <= Hex80;
else NextState <= Hex01;
end if;
when Hex80 =>
if(counter >= N) then -- if 16 mS have elapsed,
NextState <= INIT_DONE;
else NextState <= Hex80;
end if;
when INIT_DONE =>
NextState <= INIT_DONE;
-- END OF INITIALIZATION
end case;
end process COMB;
SEQ: process(reset, clk)
begin
if(reset = '1') then
CurrentState <= PowerUp;
elsif (clk'event and clk = '1') then
CurrentState <= NextState;
end if;
end process SEQ;
with CurrentState select
data <= x"38" when Hex38_1,
x"38" when Hex38_2,
x"38" when Hex38_3,
x"38" when Hex38_4,
x"06" when Hex07,
x"0C" when Hex0C,
x"01" when Hex01,
x"80" when Hex80, -- Cursor Position
x"00" when Others; -- Dont care for INIT_DONE and POWERUP states
with CurrentState select
done <= '1' when INIT_DONE,
'0' when Others;
count <= counter;
--
**************************************************************************
-- 16 bit counter
--
**************************************************************************
process(reset, clk, counter_reset)
begin
if((reset = '1') or (counter_reset = '1')) then
counter <= (others=>'0');
elsif (clk'event and clk = '1') then
if (counter = N) then -- Terminal Count value
counter <= (others=>'0');
else
counter <= counter + 1;
end if;
end if;
end process;
end Behavioral;
_________________________________________
____________________________________________________________________________________
Diligent
- CLPRefProj.vhd -- general LCD testing program
------------------------------------------------------------------
-- Author -- Dan Pederson, 2004
-- -- Barron Barnett, 2004
-- -- Jacob Beck, 2006
-- -- Tudor Ciuleanu, 2007
------------------------------------------------------------------
-- This module writes "Hello from Digilent" text onto the character
-- LCD from the CLP module
------------------------------------------------------------------
-- Revision History:
-- 05/27/2004(DanP): created
-- 07/01/2004(BarronB): (optimized) and added writeDone as output
-- 08/12/2004(BarronB): fixed timing issue on the D2SB
-- 12/07/2006(JacobB): Revised code to be implemented on a Nexys
Board
-- Changed "Hello from Digilent" to be on one line"
-- Added a Shift Left command so that the message
-- "Hello from Diligent" is shifted left by 1 repeatedly
-- Changed the delay of character writes
-- 11/21/2007(TudorC): Revised code to work with the CLP module.
-- Removed the write state machine and other unnecesary signals
-- Added backlight toggeling
------------------------------------------------------------------
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.STD_LOGIC_ARITH.ALL;
use IEEE.STD_LOGIC_UNSIGNED.ALL;
entity CLPRefProj is
Port ( rst: in std_logic; --reset input
clk: in std_logic; --clock input
sw: in std_logic; --switch input for turning backlight on
and off
--lcd input signals
DB: out std_logic_vector(7 downto 0); --output bus, used for data
transfer
RS: out std_logic; --register selection pin
RW: out std_logic; --selects between read/write modes
E: out std_logic; --enable signal for starting the data
read/write
BL: out std_logic --backlight control pin
);
end CLPRefProj;
architecture Behavioral of CLPRefProj is
------------------------------------------------------------------
-- Component Declarations
------------------------------------------------------------------
------------------------------------------------------------------
-- Local Type Declarations
-----------------------------------------------------------------
-- Symbolic names for all possible states of the state machines.
--LCD control state machine
type mstate is (
stFunctionSet, --Initialization states
stDisplayCtrlSet,
stDisplayClear,
stPowerOn_Delay, --Delay states
stFunctionSet_Delay,
stDisplayCtrlSet_Delay,
stDisplayClear_Delay,
stInitDne, --Display charachters and perform standard
operations
stActWr,
stCharDelay --Write delay for operations
);
------------------------------------------------------------------
-- Signal Declarations and Constants
------------------------------------------------------------------
--These constants are used to initialize the LCD pannel.
--FunctionSet:
--Bit 0 and 1 are arbitrary
--Bit 2: Displays font type(0=5x8, 1=5x11)
--Bit 3: Numbers of display lines (0=1, 1=2)
--Bit 4: Data length (0=4 bit, 1=8 bit)
--Bit 5-7 are set
--DisplayCtrlSet:
--Bit 0: Blinking cursor control (0=off, 1=on)
--Bit 1: Cursor (0=off, 1=on)
--Bit 2: Display (0=off, 1=on)
--Bit 3-7 are set
--DisplayClear:
--Bit 1-7 are set
signal clkCount: std_logic_vector (5 downto 0);
signal count: std_logic_vector (16 downto 0):=
"00000000000000000"; --15 bit count variable for timing delays
signal delayOK: std_logic:= '0'; --High when count has reached
the right delay time
signal OneUSClk: std_logic; --Signal is treated as a 1.5 MHz
clock
signal stCur: mstate:= stPowerOn_Delay; --LCD control state
machine
signal stNext: mstate;
signal writeDone: std_logic:= '0'; --Command set finish
type LCD_CMDS_T is array(integer range <>) of std_logic_vector(9
downto 0);
constant LCD_CMDS : LCD_CMDS_T := ( 0 => "00"&X"3C", --Function Set
1 => "00"&X"0C", --Display ON, Cursor OFF, Blink OFF
2 => "00"&X"01", --Clear Display
3 => "00"&X"02", --return home
4 => "10"&X"48", --H
5 => "10"&X"65", --e
6 => "10"&X"6C", --l
7 => "10"&X"6C", --l
8 => "10"&X"6F", --o
9 => "10"&X"20", --blank
10 => "10"&X"46", --F
11 => "10"&X"72", --r
12 => "10"&X"6F", --o
13 => "10"&X"6D", --m
14 => "10"&X"20", --blank
15 => "10"&X"44", --D
16 => "10"&X"69", --i
17 => "10"&X"67", --g
18 => "10"&X"69", --i
19 => "10"&X"6C", --l
20 => "10"&X"65", --e
21 => "10"&X"6E", --n
22 => "10"&X"74", --t
23 => "00"&X"18"); --Shift left
signal lcd_cmd_ptr : integer range 0 to LCD_CMDS'HIGH + 1 := 0;
begin
--depending on sw 1 it turns the backlight on and off
BL <= sw;
--This process counts to 50, and then resets. It is used to divide
the clock signal time.
--This makes oneUSClock peak aprox. once every 1.5 microsecond
process (CLK)
begin
if (CLK = '1' and CLK'event) then
if(clkCount = "100110") then
clkCount <= "000000";
oneUSClk <= not oneUSClk;
else
clkCount <= clkCount + 1;
end if;
end if;
end process;
--This process increments the count variable unless delayOK = 1.
process (oneUSClk, delayOK)
begin
if (oneUSClk = '1' and oneUSClk'event) then
if delayOK = '1' then
count <= "00000000000000000";
else
count <= count + 1;
end if;
end if;
end process;
--Determines when count has gotten to the right number, depending on
the state.
delayOK <= '1' when ((stCur = stPowerOn_Delay and count =
"00011010000010101") or --13333 -> 20 ms
(stCur = stFunctionSet_Delay and count = "00000000000011010")
or --26 -> 40 us
(stCur = stDisplayCtrlSet_Delay and count =
"00000000000011010") or --26 -> 40 us
(stCur = stDisplayClear_Delay and count = "00000010000101010")
or --1066 -> 1,6 ms
(stCur = stCharDelay and count =
"11111111111111111")) --65535 -> 98.3 ms - Max Delay for
character writes and shifts
else '0';
--writeDone goes high when all commands have been run
writeDone <= '1' when (lcd_cmd_ptr = LCD_CMDS'HIGH)
else '0';
--Increments the pointer so the statemachine goes through the
commands
process (lcd_cmd_ptr, oneUSClk)
begin
if (oneUSClk = '1' and oneUSClk'event) then
if ((stNext = stInitDne or stNext = stDisplayCtrlSet or stNext =
stDisplayClear) and writeDone = '0') then
lcd_cmd_ptr <= lcd_cmd_ptr + 1;
elsif stCur = stPowerOn_Delay or stNext = stPowerOn_Delay then
lcd_cmd_ptr <= 0;
else
lcd_cmd_ptr <= lcd_cmd_ptr;
end if;
end if;
end process;
--This process runs the LCD state machine
process (oneUSClk, rst)
begin
if oneUSClk = '1' and oneUSClk'Event then
if rst = '1' then
stCur <= stPowerOn_Delay;
else
stCur <= stNext;
end if;
end if;
end process;
--This process generates the sequence of outputs needed to initialize
and write to the LCD screen
process (stCur, delayOK, writeDone, lcd_cmd_ptr)
begin
case stCur is
--Delays the state machine for 20ms which is needed for proper
startup.
when stPowerOn_Delay =>
if delayOK = '1' then
stNext <= stFunctionSet;
else
stNext <= stPowerOn_Delay;
end if;
--This issues the function set to the LCD as follows
--8 bit data length, 1 lines, font is 5x8.
when stFunctionSet =>
stNext <= stFunctionSet_Delay;
--Gives the proper delay of 37us between the function set and
--the display control set.
when stFunctionSet_Delay =>
if delayOK = '1' then
stNext <= stDisplayCtrlSet;
else
stNext <= stFunctionSet_Delay;
end if;
--Issuse the display control set as follows
--Display ON, Cursor OFF, Blinking Cursor OFF.
when stDisplayCtrlSet =>
stNext <= stDisplayCtrlSet_Delay;
--Gives the proper delay of 37us between the display control set
--and the Display Clear command.
when stDisplayCtrlSet_Delay =>
if delayOK = '1' then
stNext <= stDisplayClear;
else
stNext <= stDisplayCtrlSet_Delay;
end if;
--Issues the display clear command.
when stDisplayClear =>
stNext <= stDisplayClear_Delay;
--Gives the proper delay of 1.52ms between the clear command
--and the state where you are clear to do normal operations.
when stDisplayClear_Delay =>
if delayOK = '1' then
stNext <= stInitDne;
else
stNext <= stDisplayClear_Delay;
end if;
--State for normal operations for displaying characters, changing
the
--Cursor position etc.
when stInitDne =>
stNext <= stActWr;
when stActWr =>
stNext <= stCharDelay;
--Provides a max delay between instructions.
when stCharDelay =>
if delayOK = '1' then
stNext <= stInitDne;
else
stNext <= stCharDelay;
end if;
end case;
end process;
RS <= LCD_CMDS(lcd_cmd_ptr)(9);
RW <= LCD_CMDS(lcd_cmd_ptr)(8);
DB <= LCD_CMDS(lcd_cmd_ptr)(7 downto 0);
E <= '1' when stCur = stFunctionSet or stCur = stDisplayCtrlSet or
stCur = stDisplayClear or stCur = stActWr
else '0';
end Behavioral;
Article: 140807
Andy wrote:
> Here ya go...
>
> State2 : process(CLK)
> begin
> if rising_edge(CLK) then
> if SINI = '1' then
> State2 <= Idle_S;
> else
> case State2 is
> when Idle_S =>
> if A1 = '1' then
> State2 <= X_S;
> end if;
> when X_S =>
> if A2 = '1' then
> State2 <= Idle_S;
> end if;
> end case;
> end if; -- sini
> end if; -- clk
> end process;
Thanks for taking the time to post this simplified solution.
This thread demonstrates the clarity provided by
minimizing the number of processes in a design entity.
More importantly, it shows the downside of
using an asynchronous process for synthesis.
-- Mike Treseler
Article: 140808On May 26, 11:00=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > On May 25, 12:47=A0am, yuchi...@gmail.com wrote: > > > > > > > Hexagon is possible, but it would generate more trouble for bus > interconnections and it would generate waste materials along chip > boundaries. > > For more information, Xilinx patent: 7274214, "Efficient tile layout > for a programmable logic device.pdf"http://www.google.com/patents?id=3DdG= eEAAAAEBAJ&dq=3Dpatent:7274214&as_dr... > > I have carefully and thoroughly read the patent, but with purposes > different from yours. It is very interesting and instructive. > > Weng- Hide quoted text - > > - Show quoted text - Spherical would be idealArticle: 140809
On May 26, 7:46=A0am, jleslie48 <j...@jonathanleslie.com> wrote: > On May 22, 8:23 pm, jleslie48 <j...@jonathanleslie.com> wrote: > > > > > On May 22, 5:55 pm, Muzaffer Kal <k...@dspia.com> wrote: > > > > On Fri, 22 May 2009 14:20:59 -0700 (PDT), jleslie48 > > > > <j...@jonathanleslie.com> wrote: > > > >On May 22, 5:26 pm, doug <x...@xx.com> wrote: > > > > >> Only FFs have reset. > > > > >that doesn't mean anything to me. =A0maybe I inlcuded too much code = in > > > >the snippet, =A0the only part of the code > > > >that is causing the issue I believe is this: > > > > >--------------------------------------------------------------------= --------------- > > > > =A0 type reg_file_type is array (2**W-1 downto 0) of > > > > =A0 =A0 =A0 =A0std_logic_vector(B-1 downto 0); > > > > =A0 signal array_reg: reg_file_type; > > > >--------------------------------------------------------------------= --------------- > > > > >the error message in question has no issue with the reset. =A0its > > > >complaining about <array_reg> > > > > The "warning" is just telling you that it couldn't map your "array" t= o > > > memory. Doug has said the reason that couldn't be done probably was > > > that you have some code which says: > > > > if (reset) > > > array <=3D 0 > > > > or something similar. As "only ffs have reset" this "array" can't be > > > mapped to memory. If you have code like this, remove it, add an > > > initial statement to clear array instead and try again. > > > -- > > > Muzaffer Kal > > > > DSPIA INC. > > > ASIC/FPGA Design Services > > > >http://www.dspia.com > > > Thank you, that makes sense. =A0I'll have to check. > > C:\jon\fpga_uartjl_01\Pchu_cc02\ms_d04\source>grep -in -B3 -A3 > array_reg fifo.vhd > > 23-architecture arch of fifo is > 24- =A0 type reg_file_type is array (2**W-1 downto 0) of > 25- =A0 =A0 =A0 =A0std_logic_vector(B-1 downto 0); > 26: =A0 signal array_reg: reg_file_type; > 27- =A0 signal w_ptr_reg, w_ptr_next, w_ptr_succ: > 28- =A0 =A0 =A0std_logic_vector(W-1 downto 0); > 29- =A0 signal r_ptr_reg, r_ptr_next, r_ptr_succ: > -- > 39- =A0 process(clk,reset) > 40- =A0 begin > 41- =A0 =A0 if (reset=3D'1') then > 42: =A0 =A0 =A0 =A0array_reg <=3D (others=3D>(others=3D>'0')); > 43- =A0 =A0 elsif (clk'event and clk=3D'1') then > 44- =A0 =A0 =A0 =A0if wr_en=3D'1' then > 45: =A0 =A0 =A0 =A0 =A0 array_reg(to_integer(unsigned(w_ptr_reg))) > 46- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <=3D w_data; > 47- =A0 =A0 =A0 =A0end if; > 48- =A0 =A0 end if; > 49- =A0 end process; > 50- =A0 -- read port > 51: =A0 r_data <=3D array_reg(to_integer(unsigned(r_ptr_reg))); > 52- =A0 -- write enabled only when FIFO is not full > 53- =A0 wr_en <=3D wr and (not full_reg); > 54- > > Ok, so here's all the code pertaining to array_reg, specifically lines > 42, 45, and 51. =A0From what I can understand, it seems that the > professionals here are concerned about line 42; the one resulting from > the reset signal. =A0What would be the correct way to implement this > concept? Simply delete the asynchronous reset stuff in lines 41 and 42, and change the "elsif" on line 43 to a simple "if." > In C I would of just done a memset(array_reg, 0, sizeof(array_reg)) > but we ain't in C world any more... Indeed -- think HARDWARE. Since you are describing a FIFO, there's no need to reset the memory. Simply resetting the read and write pointers effectively clears the memory. You will never read from an empty FIFO and a FIFO write guarantees that you read valid data. -aArticle: 140810
On Tue, 26 May 2009 07:46:48 -0700 (PDT), jleslie48 <jon@jonathanleslie.com> wrote: >39- process(clk,reset) >40- begin >41- if (reset='1') then >42: array_reg <= (others=>(others=>'0')); >43- elsif (clk'event and clk='1') then >44- if wr_en='1' then >45: array_reg(to_integer(unsigned(w_ptr_reg))) >46- <= w_data; >47- end if; >48- end if; >49- end process; >50- -- read port >51: r_data <= array_reg(to_integer(unsigned(r_ptr_reg))); >52- -- write enabled only when FIFO is not full >53- wr_en <= wr and (not full_reg); >54- > >Ok, so here's all the code pertaining to array_reg, specifically lines >42, 45, and 51. From what I can understand, it seems that the >professionals here are concerned about line 42; the one resulting from >the reset signal. What would be the correct way to implement this >concept? > Remove reset from line 39, delete lines 41 & 42 and change elsif on 43 to if. >In C I would of just done a memset(array_reg, 0, sizeof(array_reg)) >but we ain't in C world any more... No you're not but things are not that different. Treat this array contents as automatic variables ie don't use the values if you haven't written to them first. Also in an FPGA, you can even get it to be cleared too but you have to do a little bit more work. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 140811
> I've seen quite a few papers about multiprocessor microblaze systems > or multiprocessor nios systems. I'm somewhat curious though, is anyone > using this kind of solution in a commercial setting? > I know of military companies that use this kind of multicore processors. They usually put embedded solutions and usually need parallel computation. > I can understand it for educational purposes, but for commercial > purposes, wouldn't it be better to just buy an embedded multicore > processor of some sort? Of course, but this kind of devices have been designed to find the ideal solution. Once you have found it, you could but a concret (and EXPENSIVE) multiprocessor. This is my poor opinion. my best regard Andreas.Article: 140812
On May 22, 11:30=A0am, rickman <gnu...@gmail.com> wrote: > I figured out what was wrong. =A0I was using constant symbols for the > value and XST does not seem to recognize any user defined symbols. =A0So > I had to use integer values. It will accept string, std_logic, std_logic_vector and boolean, too. The reason it doesn't accept user-defined symbols is because in the synthesis tool script (or GUI) there's no way to indicate how those symbols are defined. -aArticle: 140813
On May 26, 2:58 pm, Andy Peters <goo...@latke.net> wrote:
> On May 26, 7:46 am, jleslie48 <j...@jonathanleslie.com> wrote:
>
>
>
> > On May 22, 8:23 pm, jleslie48 <j...@jonathanleslie.com> wrote:
>
> > > On May 22, 5:55 pm, Muzaffer Kal <k...@dspia.com> wrote:
>
> > > > On Fri, 22 May 2009 14:20:59 -0700 (PDT), jleslie48
>
> > > > <j...@jonathanleslie.com> wrote:
> > > > >On May 22, 5:26 pm, doug <x...@xx.com> wrote:
>
> > > > >> Only FFs have reset.
>
> > > > >that doesn't mean anything to me. maybe I inlcuded too much code in
> > > > >the snippet, the only part of the code
> > > > >that is causing the issue I believe is this:
>
> > > > >-----------------------------------------------------------------------------------
> > > > > type reg_file_type is array (2**W-1 downto 0) of
> > > > > std_logic_vector(B-1 downto 0);
> > > > > signal array_reg: reg_file_type;
> > > > >-----------------------------------------------------------------------------------
>
> > > > >the error message in question has no issue with the reset. its
> > > > >complaining about <array_reg>
>
> > > > The "warning" is just telling you that it couldn't map your "array" to
> > > > memory. Doug has said the reason that couldn't be done probably was
> > > > that you have some code which says:
>
> > > > if (reset)
> > > > array <= 0
>
> > > > or something similar. As "only ffs have reset" this "array" can't be
> > > > mapped to memory. If you have code like this, remove it, add an
> > > > initial statement to clear array instead and try again.
> > > > --
> > > > Muzaffer Kal
>
> > > > DSPIA INC.
> > > > ASIC/FPGA Design Services
>
> > > >http://www.dspia.com
>
> > > Thank you, that makes sense. I'll have to check.
>
> > C:\jon\fpga_uartjl_01\Pchu_cc02\ms_d04\source>grep -in -B3 -A3
> > array_reg fifo.vhd
>
> > 23-architecture arch of fifo is
> > 24- type reg_file_type is array (2**W-1 downto 0) of
> > 25- std_logic_vector(B-1 downto 0);
> > 26: signal array_reg: reg_file_type;
> > 27- signal w_ptr_reg, w_ptr_next, w_ptr_succ:
> > 28- std_logic_vector(W-1 downto 0);
> > 29- signal r_ptr_reg, r_ptr_next, r_ptr_succ:
> > --
> > 39- process(clk,reset)
> > 40- begin
> > 41- if (reset='1') then
> > 42: array_reg <= (others=>(others=>'0'));
> > 43- elsif (clk'event and clk='1') then
> > 44- if wr_en='1' then
> > 45: array_reg(to_integer(unsigned(w_ptr_reg)))
> > 46- <= w_data;
> > 47- end if;
> > 48- end if;
> > 49- end process;
> > 50- -- read port
> > 51: r_data <= array_reg(to_integer(unsigned(r_ptr_reg)));
> > 52- -- write enabled only when FIFO is not full
> > 53- wr_en <= wr and (not full_reg);
> > 54-
>
> > Ok, so here's all the code pertaining to array_reg, specifically lines
> > 42, 45, and 51. From what I can understand, it seems that the
> > professionals here are concerned about line 42; the one resulting from
> > the reset signal. What would be the correct way to implement this
> > concept?
>
> Simply delete the asynchronous reset stuff in lines 41 and 42, and
> change the "elsif" on line 43 to a simple "if."
>
> > In C I would of just done a memset(array_reg, 0, sizeof(array_reg))
> > but we ain't in C world any more...
>
> Indeed -- think HARDWARE.
>
> Since you are describing a FIFO, there's no need to reset the memory.
> Simply resetting the read and write pointers effectively clears the
> memory. You will never read from an empty FIFO and a FIFO write
> guarantees that you read valid data.
>
> -a
quite right,
the other process has:
process(clk,reset)
begin
if (reset='1') then
w_ptr_reg <= (others=>'0');
r_ptr_reg <= (others=>'0');
full_reg <= '0';
empty_reg <= '1';
and as my pointers get reset who cares about the data. System
resources went dramatically down as a result of the changes, however
two warnings are now being generated that were never there before:
WARNING Route - CLK Net:clk_2mhz is being routed on general routing
resources. If you are trying to use local clocking techniques,
evaluate the placement of the clock's source and loads to ensure it
meets the guidelines for local clocking. Otherwise, consider placing
this clock on a dedicated clock routing resource. For more information
on clock routing resources, see the target architecture's user guide.
WARNING Route - CLK Net:clk_7812hz is being routed on general routing
resources. If you are trying to use local clocking techniques,
evaluate the placement of the clock's source and loads to ensure it
meets the guidelines for local clocking. Otherwise, consider placing
this clock on a dedicated clock routing resource. For more information
on clock routing resources, see the target architecture's user guide.
I can't imagine why these are showing up as a result of "fixing" the
other error.
Article: 140814
Andreas Ehliar wrote:
> It is straight forward in Verilog as well.
I agree, other than filling in
that ... and so on... part.
Thanks for the posting.
You have cracked the code and discovered verilog variables.
I won't tell anyone ;)
> This is taken from an Ethernet
> CRC32 module I wrote a long time ago:
I did it in vhdl with a compile time
constant table and a serial crc_shift function
overloaded for the parallel case something like:
begin
crc_v := crc; -- starting value
for i in data'range loop -- call serial shift below for each bit
-- left to right
crc_v := crc_shift(data(i), crc_v, crc_type);
end loop;
return crc_v;
end function crc_shift;
-- Mike Treseler
__________________________________________________
constant crc_table : crc_table_t := (
ppp32 => -- ethernet, hdlc, ppp, AAL5, fddi,
(
crc_len => 32,
poly_vec =>
(26|23|22|16|12|11|10|8|7|5|4|2|1|0 => '1', others => '0'),
crc_init => (others => '1'),
remainder => x"c704_dd7b"
), ...
_____________________________________________________
-- Base serial shifter, all of the other crc_shifts end up here
-- This gets called n times for the parallel versions above
function crc_shift -- Serial in, unsigned return
( data : in std_ulogic; -- input bit
crc : in unsigned; -- crc starting value
crc_type : in crc_t
)
return unsigned is
variable crc_v : unsigned(crc'range); -- CRC register
constant reg_len : natural :=
crc_table(crc_type).crc_len; -- look up length
subtype crc_vec is unsigned(reg_len-1 downto 0);
-- chop table poly to length
constant mask : crc_vec :=
crc_table(crc_type).poly_vec(crc_vec'range);
begin
crc_v := crc sll 1; -- shift it
if (crc(crc'left) xor data) = '1' then
-- maybe invert mask bits
crc_v := crc_v xor mask;
end if;
return unsigned(crc_v);
-- returns whole register each shift
end function crc_shift;
Article: 140815On Fri, 15 May 2009 06:09:26 -0700 (PDT), Marteno Rodia <marteno_rodia@o2.pl> wrote: >> Which device are you using and which IOs are you trying to use? > >I'm to use the Virtex-5 LXT/SXT PCI Expres board the AES-XLX-V5SXT- >PCIE95-G circuit. There are 4 clock signals and I'm using following >pins (according to the board documentation): > >sys_clk_p - E4 >sys_clk_n - D4 >sys_clk_p - D8 >sys_clk_n - C8 These are MGTREFCLK pins which are not meant for general use. You need to instantiate a RocketIO transceiver to be able to use them. Use the coregen to generate the RocketIO block. If you want to bring these to the fabric, you need to connect a BUFG from a RocketIO. > >> Please explain how you understand the problem as you mentioned above > >Besides the VHDL code, Xilinx ISE needs an additional file in a >proprietary format (UCF). I think the problem is I don't know how to >specify all the necessary constraints in the file (lack of experience >with Xilinx). If you use the Coregen to generate the core you have to use for these pins (GTP_DUAL), you will also get the associated UCF file. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 140816
On May 27, 3:25=A0am, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > I just use the <project>.xise file. Starting the gui with just that file = in > the project directory produces all the other files. Assuming you meant '.ise' not '.xise' (apologies if there really is a .xise file, I haven't seen one) - as I mentioned earlier, we cannot use the .ise file as an input to our build system because it constantly changes. This also means we would prefer not to have it tracked by our source control tool (git) as a constantly changing file is nothing short of exceptionally annoying. So if we can generate an .ise at build-time from a TCL script, we can provide a way to generate a non-controlled .ise for use locally in the GUI tool. I still don't want to use the .ise as a build input.Article: 140817
"David Antliff" <david.antliff@gmail.com> wrote in message news:b284f6e3-e758-47e7-a392-2e0ce77c73f8@p6g2000pre.googlegroups.com... On May 27, 3:25 am, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > I just use the <project>.xise file. Starting the gui with just that file > in > the project directory produces all the other files. Assuming you meant '.ise' not '.xise' (apologies if there really is a .xise file, I haven't seen one) - as I mentioned earlier, we cannot use the .ise file as an input to our build system because it constantly changes. This also means we would prefer not to have it tracked by our source control tool (git) as a constantly changing file is nothing short of exceptionally annoying. So if we can generate an .ise at build-time from a TCL script, we can provide a way to generate a non-controlled .ise for use locally in the GUI tool. I still don't want to use the .ise as a build input. ========= I really did mean explicitly .xise, as opposed to .ise. It's apparently new with 11.1. It looks like well formed XML, but I didn't look in any detail. The .ise file looks to be a TCL script, likely generated from .xise.Article: 140818
This example shows one way to handle outputs, but inserts a one clock
delay on the output.
State2 : process(CLK)
begin
if rising_edge(CLK) then
turn_on <= '0';
if SINI = '1' then
State2 <= Idle_S;
else
case State2 is
when Idle_S =>
if A1 = '1' then
turn_on <= '1';
State2 <= X_S;
end if;
when X_S =>
if A2 = '1' then
State2 <= Idle_S;
end if;
end case;
end if; -- sini
end if; -- clk
end process;
If you want to avoid the delay, just assert the output when you
transition into the states in which you want it on. I think it was
Jonathan Bromley that demonstrated a method, using variables, to
describe state machine outputs more easily in a single clocked
process.
It's not that hard to do, and you don't get latches, ever!
If you really prefer dual-process state machines, there are proven,
easy ways to avoid latches in them (like default "State <= State_NS"
assignments). Quite frankly, I'd prefer the synthesis vendors work on
other optimizations that are more important to quality of results,
than avoiding inferring latches from poorly written RTL code.
Andy
Article: 140819On May 27, 10:03=A0am, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > I really did mean explicitly .xise, as opposed to .ise. It's apparently n= ew > with 11.1. It looks like well formed XML, but I didn't look in any detail= . > The .ise file looks to be a TCL script, likely generated from .xise. Ok - sorry for the confusion. This sounds useful, although we haven't upgraded to 11.1 just yet. I'll definitely keep it in mind when we do. Thanks for the info.Article: 140820
andrew.newsgroup@gmail.com wrote:
>> On the speedbar:
>> center-click project,
>> right-click and hold down, speedbar, rescan-project
>
> Thanks Mike, but I just don't see the rescan-project option.
Maybe you are in the wrong mode.
Try typing 'H' with the mouse in the speedbar.
Here's mine from suse 11
http://mysite.verizon.net/miketreseler/speedbar.png
>
> Here is what I do:
> open a .vhd file
> vhdl menu, select speedbar to open up the speedbar window
>
> When I right-click, hold down, speedbar: I don't see the rescan-
> project option. I see a list of options starting with Update, Auto-
> update, .... Customise, Close, Quit.
Hmm. That sounds like the VHDL, Options menu -- not the speedbar
> I don't quite understand your hint "center-click the project file".
That does a vhdl-set-file
> vhdl menu export project creates a .prj file. But this file doesn't
> show up in the speed bar? Is this the .prj file you are suggesting I
> center-click in the speedbar?
I don't use .prj files.
I use Vhdl, Project, Customize project.
Maybe you don't have a project defined?
Good luck.
-- Mike
http://mysite.verizon.net/miketreseler/speedbar.png
GNU Emacs 22.2.1 (i586-suse-linux-gnu, X toolkit, Xaw3d scroll bars)
of 2008-09-11 on yggdrasil
VHDL Mode 3.33.6 (2005-08-30)
Article: 140821On May 26, 3:21=A0pm, Andy <jonesa...@comcast.net> wrote: > This example shows one way to handle outputs, but inserts a one clock > delay on the output. > > State2 : process(CLK) > begin > =A0 =A0if rising_edge(CLK) then > =A0 =A0 =A0 turn_on <=3D '0'; > =A0 =A0 =A0 if SINI =3D '1' then > =A0 =A0 =A0 =A0 State2 <=3D Idle_S; > =A0 =A0 =A0 else > =A0 =A0 =A0 =A0 case State2 is > =A0 =A0 =A0 =A0 when Idle_S =3D> > =A0 =A0 =A0 =A0 =A0 if A1 =3D '1' then > =A0 =A0 =A0 =A0 =A0 =A0 turn_on <=3D '1'; > =A0 =A0 =A0 =A0 =A0 =A0 State2 <=3D X_S; > =A0 =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 =A0 when X_S =3D> > =A0 =A0 =A0 =A0 =A0 if A2 =3D '1' then > =A0 =A0 =A0 =A0 =A0 =A0 State2 <=3D Idle_S; > =A0 =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 =A0 end case; > =A0 =A0 =A0 end if; -- sini > =A0 =A0end if; -- clk > end process; > > If you want to avoid the delay, just assert the output when you > transition into the states in which you want it on. I think it was > Jonathan Bromley that demonstrated a method, using variables, to > describe state machine outputs more easily in a single clocked > process. > > It's not that hard to do, and you don't get latches, ever! > > If you really prefer dual-process state machines, there are proven, > easy ways to avoid latches in them (like default "State <=3D State_NS" > assignments). Quite frankly, I'd prefer the synthesis vendors work on > other optimizations that are more important to quality of results, > than avoiding inferring latches from poorly written RTL code. > > Andy Hi Andy, "If you really prefer dual-process state machines, there are proven, easy ways to avoid latches in them (like default "State <=3D State_NS" assignments)." Very good suggestions !!! I will follow it in all my designs starting today. Actually I give a default value at head of each of important states, not for full state machine. But your method of one process with turn-on signal delayed by 1 clock is not acceptable to me. That is the fatal fault of one process and the main reason for me to use dual-process method. One may like vegetables and others may like beef and pork. There is no need to compare between two methods, I know, it is a long crusade in VHDL industry. WengArticle: 140822
On May 27, 12:17=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > On May 25, 7:14=A0pm, sbatt...@yahoo.co.jp wrote: > > > > > On May 26, 3:58=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > > > > On May 25, 9:16=A0am, Peter Alfke <al...@sbcglobal.net> wrote: > > > > > On May 25, 2:11=A0am, sbatt...@yahoo.co.jp wrote: > > > > > > Hi guys, > > > > > At the moment I'm waiting to find out whether I will be using Xil= inx > > > > > or Actel for my project, and so I'm putting it together for both = just > > > > > in case. > > > > > > In the Actel IP cores, there is an array adder which allows a goo= d > > > > > number of inputs, and there's some optional pipelining. I figure = it's > > > > > sufficient to just drop this in and wire up as many inputs as I n= eed. > > > > > > Xilinx IP cores seem to have only 2-input adders, and I guess the= se > > > > > are probably inferred by XST with the + operator anyway, so I don= 't > > > > > want to bother with the IP core gen unless there's some reason wh= y I > > > > > should. > > > > > Supposing I want: > > > > > > Result <=3D A + B + C + D + E; > > > > > Note, I used only five inputs in my example for brevity, I will h= ave > > > > > more like 25 in my actual system. > > > > > > (looking in the XST manual, I can either pad the inputs with lead= ing > > > > > zeros or convert to integer and back to std_logic_vector to get c= arry > > > > > bits to fill my wider result) > > > > > > At the end of the day, when I synthesize this, would there be any > > > > > difference between coding it in stages (adding pairs of two toget= her, > > > > > then adding their sums together, and so on until all are added up= ) and > > > > > just putting A+B+C+D+E in one statement? > > > > > All I can think of is that (depending how well conversions to/fro= m > > > > > integer are optimized in XST) I might save a few bits of space in= the > > > > > first stages. > > > > > Using the bit padding method, I suppose that all of the adders in= the > > > > > first stages would wind up unnecessarily being the same width as = the > > > > > result. > > > > > > Anyway, I'm just curious how this will end up working... any insi= ght > > > > > appreciated! > > > > > > Steve > > > > > If I understand you right, you have 25 parallel inputs, each sendin= g > > > > you bit-serial data. > > > > You need to convert the 25 inputs into one 6-bit binary word, and t= hen > > > > accumulate these words with increasing (or decreasing) binary weigh= t. > > > > > Conversion of 25 lines to 6 bits can be done in many ways, includin= g > > > > sequential scanning or shifting, which requires a faster clock of > > > > > 1.5 MHz. > > > > But here is an unconventional and simpler way: > > > > Use 13 inputs as address to one port of a BlockRAM with 4 parallel > > > > outputs =A0(8K x 4) > > > > Use the remaining 12 inputs as address to the other port of the sam= e > > > > BlockRAM. > > > > Store the conversion of (# of active inputs to a binary value) in t= he > > > > BlockRAM. > > > > > Add the two 4 bit binary words together to form a 5-bit word that > > > > always represents the number of active inputs. > > > > Then feed this 5-bit value into a 13-bit accumulator, where you shi= ft > > > > the content after each clock tick. > > > > > This costs you one BlockRAM plus three or four CLBs in Xilinx > > > > nomenclature, a tiny portion of the smallest Spartan or Virtex devi= ce, > > > > and it could be run a few thousand times faster than you need. > > > > If you have more than 26 inputs, just add another BlockRAM for a to= tal > > > > of up to 52 inputs, and extend the adder and accumulator by one bit= . > > > > (Yes, I know in Spartan you are limited to 12 address inputs, (4K x > > > > 4), but you can add the remaining bit outside...) > > > > > Peter Alfke, from home.- Hide quoted text - > > > > > - Show quoted text - > > > > Hi Steve, > > > 1. Set up a 16*8 FIFO; > > > 2. Each of 25 data sources is first registered in its 8-bit register > > > with valid bit when data bits are full from its serial data source; > > > 3. When valid =3D '1', push the data into FIFO and clear the valid bi= t; > > > 4. Set up a 13-bit register with initialized 0 data when a new > > > calculation starts; > > > 5. When FIFO is not empty, add 13-bit register with high 5-bit being > > > '0' and low 8-bit from FIFO output. > > > > There is no need for 25 data sources. > > > > Weng > > > Hi Weng, > > > I'm sorry I didn't explain in full what I am doing. There is only one > > serial source feeding a string of delay lines, and at the end of the > > delay lines is a 5x5 array of 8-bit registers whose sum I need to > > calculate. Each time the serial source gets a byte in, everything in > > the delay lines and 5x5 array gets shifted, and I have a new sum to > > calculate (this happens once every ms or so, though, so I'm not really > > worried about carry propagation). > > So in this case, I don't think a FIFO would help any? > > > As far as I can see, as noted in my reply to Andy's post, my options > > are (a slightly modified version of) his suggested accumulator > > solution, or feeding my 25 inputs into a tree of adders. There could > > be some other clever solution though? > > > I was originally just wondering if XST would generate such a tree with > > 25 operands in a sum statement, or if I would have to build the tree > > myself in a few statements. > > The Actel array adder IP apparently uses the DADDA algorithm to handle > > multiple inputs, but I haven't seen anything in the XST docs about > > multiple-operand addition.- Hide quoted text - > > > - Show quoted text - > > "Each time the serial source gets a byte in, everything in =A0the delay > lines and 5x5 array gets shifted, and I have a new sum to > calculate", OK, there is no FIFO needed. > > Every time you get a byte from the serial input, a 13-bit adder is > used to add the data with high 5-bit '0' on the same clock when the > byte is being shifted. > > Weng Alright, thanks for all the replies! For now I guess I will go with having an accumulator on each row of the array, adding the new data that is being shifted in, and subtracting off the end of each row that is being shifted out into nowhere land. Including the accumulators, there are then 9 adders and 5 subtracters. Cheers, SteveArticle: 140823
I'm currently running ISE on Windows XP. I have a E8500, and am considering upgrading to a Core i7 920. Anybody have a feeling for how much speed improvement this will give me? ThanksArticle: 140824
On Tue, 26 May 2009 21:28:58 -0700, "Pete Fraser" <pfraser@covad.net> wrote: >I'm currently running ISE on Windows XP. >I have a E8500, and am considering upgrading >to a Core i7 920. Anybody have a feeling for how >much speed improvement this will give me? You'll be going from a 3.16 GHz 6M L2 machine to a 2.66 GHz 8M L2 machine. Given that ISE (or most apps it calls) is a single-threaded integer app it's possible that you'll see very small to negative improvement. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.com
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