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
KJ wrote: (snip) > Pipelining means simply to take a clock cycle (or more) to produce a result. > What this essentially does is to spread out a computation so that part of it > gets done in one clock cycle, another part gets done in some other clock > cycle. This is especially convenient with FPGAs which usually have a FF at the output of each LUT. > The reason you would do such a seemingly counterproductive thing is > because sometimes the time it takes to do the entire calculation would mean > that the system clock would have to slow down. By breaking the problem into > smaller chunks, each chunk can be done faster. Assuming that you have a register, a big complicated block of logic, followed by another register, pipelining allows you to speed up the clock by adding additional registers inside the block of logic. One point, though. Pipelining allows an increased throughput, though usually at increased latency. If you only want one it won't help speed it up. It is when you want more than one that it helps. The first result comes out after N (number of pipeline stages) clock cycles. After that results come out each cycle. -- glenArticle: 126751
hey guys i hope u can help me out... i want to design a simple traffic
light controller according to the 4 states shown in the code below. my
only problem is that my signal state_reg is not changing form one
state to another. this is because the counter i included in the the
code as a process is not working. green to yellow time wait is 30 sec
and yellow to red is 5 sec. my clock period will be 5 sec. so can
anyone help me out
----------------------------------------------------------------------------------------------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use IEEE.std_logic_unsigned.all;
entity TLC is
port(
clk,reset, sa, sb:in std_logic;
Ga, Ya, Ra, Gb, Yb, Rb:out std_logic
);
end TLC;
architecture Behavioral of TLC is
type state_type is (a, b, c, d);
signal state_reg, state_next: state_type;
signal Pre_Q, Q: std_logic_vector(3 downto 0);
signal count, clear: std_logic;
begin
-- behavior describe the counter
process(clk, count, clear)
begin
if (clear = '0') then
Pre_Q <= Pre_Q - Pre_Q;
elsif (clk='1' and clk'event) then
if (count = '1') then
Pre_Q <= Pre_Q + 1;
end if;
end if;
Q <= Pre_Q;
end process;
-- state register
process(clk,reset)
begin
if(reset='0') then
state_reg <= a;
elsif (clk'event and clk='1') then
state_reg <= state_next;
end if;
end process;
-- next state logic
process(state_reg,Q,sa,sb)
begin
case state_reg is
when a =>
if(sa = '1' and sb = '0')then
state_next <= a;
elsif (sa = '0' and sb = '1') then
count <= '1';
if(Q = "0110") then
state_next <= b;
end if;
end if;
when b =>
if(Q = "0111") then
state_next <= c;
count <= '0';
elsif(sa = '1') then
state_next <= b;
end if;
when c =>
if(sa = '0' and sb = '1') then
state_next <= c;
elsif (sa = '1' and sb ='0') then
clear <= '0';
count <= '1';
if(Q = "0110") then
state_next <= d;
end if;
end if;
when d =>
if(Q = "0111") then
state_next <= a;
count <= '0';
elsif(sb = '1') then
state_next <= d;
end if;
end case;
end process;
process (state_reg)
begin
Ga <= '1'; Ya <= '0'; Ra <= '0';
Gb <= '0'; Yb <= '0'; Rb <= '1';
case state_reg is
when a =>
when b =>
Ga <= '0';
Ya <= '1';
when c =>
Ya <= '0';
Ra <= '1';
Gb <= '1';
when d =>
Gb <= '0';
Yb <= '1';
end case;
end process;
end Behavioral;
--------------------------------------------------------------------------------------------------------------------------------------------------------
Article: 126752"rickman" <gnuarm@gmail.com> wrote in message news:2c8d9068-fbe9-497d-8d34-5627976b7332@e23g2000prf.googlegroups.com... > On Nov 27, 3:43 pm, fl <rxjw...@gmail.com> wrote: > "Describing hardware" means you can only use constructs that the > compiler understands. See the difference? As I pointed out in my first post, what many people refer to as 'not synthesizable' really means that they can't find a tool that supports the code as it is written. Something that is 'not synthesizable' can never be built. Living with the limitations of a particular tool(s) is not the same thing at all. > Simulation operates on the > full language. Synthesis only works with a subset that actually > describes hardware. > Agreed. > The examples are far too numerous to list, but here is one. <snip> > To make this unsynthesizable in a way that is sometimes attempted by > newbies... > > Example2: process (SysClk, Reset) begin > if (Reset = '1') then > DataOutReg <= (others => '0'); > elsif (rising_edge(SysClk) or falling_edge(SysClk)) then > if (SCFG_CMD = '1') THEN > DataOutReg <= TT & SD & PCMT0 & PCMT1 & WP_SDO0 & WP_SDO1 & DTR & > RTS; > end if; > end if; > end process Example2; > > You can imagine a register that clocks on both the rising and falling > edge, but you can't build it in an FPGA. But that does not imply that it couldn't be synthesized using two sets of flip flops whose results get combined. You might not find a synthesis tool in 2007 that accepts the above code, but that doesn't mean that there won't be one in 2008 that will. Whether there is such a tool or not depends on how many users scream to brand A and X that they really need this. It can be synthesized, just not how you are focusing on how you think it must be synthesized. > > Every synthesis tool I have ever used will give you many examples of > valid hardware description code for you to examine. I am not so > familiar with the Altera tools, but I know the Xilinx tools have > provided good examples. Just download one of these free packages and > take it for a test ride. Agreed. Since one needs to get today's job done with tools you have today you need to understand the limitation of the tools as they are today. I've submitted dozens of web cases in areas that should be supported but errored out or produced incorrect results. The tools were updated and improved, thus changing what was not synthesizable into something that is. Each of those things were areas where the synthesis tool did not support a language construct and it should. Bottom line right now for the code I right, I'm finding Altera way ahead of Xilinx and Synplify so I'm working with X and S to get their tools improved so that they too can have less stuff that some would consider to be 'not synthesizable'. KJArticle: 126753
On Nov 30, 5:12 pm, tang <tarangpatel2elect...@gmail.com> wrote: > hey guys i hope u can help me out... i want to design a simple traffic > light controller according to the 4 states shown in the code below. my > only problem is that my signal state_reg is not changing form one > state to another. this is because the counter i included in the the > code as a process is not working. green to yellow time wait is 30 sec > and yellow to red is 5 sec. my clock period will be 5 sec. so can > anyone help me out > > ------------------------------------------------------------------------------------------------------------------------------------------------------------ > library ieee; > use ieee.std_logic_1164.all; > use ieee.std_logic_arith.all; > use IEEE.std_logic_unsigned.all; > > entity TLC is > port( > clk,reset, sa, sb:in std_logic; > Ga, Ya, Ra, Gb, Yb, Rb:out std_logic > ); > end TLC; > > architecture Behavioral of TLC is > > type state_type is (a, b, c, d); > signal state_reg, state_next: state_type; > signal Pre_Q, Q: std_logic_vector(3 downto 0); > signal count, clear: std_logic; > > begin > > -- behavior describe the counter > process(clk, count, clear) > begin > if (clear = '0') then > Pre_Q <= Pre_Q - Pre_Q; > elsif (clk='1' and clk'event) then > if (count = '1') then > Pre_Q <= Pre_Q + 1; > end if; > end if; > Q <= Pre_Q; > end process; > > -- state register > > process(clk,reset) > begin > if(reset='0') then > state_reg <= a; > elsif (clk'event and clk='1') then > state_reg <= state_next; > end if; > end process; > > -- next state logic > > process(state_reg,Q,sa,sb) > begin > > case state_reg is > when a => > if(sa = '1' and sb = '0')then > state_next <= a; > elsif (sa = '0' and sb = '1') then > count <= '1'; > if(Q = "0110") then > state_next <= b; > end if; > end if; > > when b => > > if(Q = "0111") then > state_next <= c; > count <= '0'; > elsif(sa = '1') then > state_next <= b; > end if; > > when c => > if(sa = '0' and sb = '1') then > state_next <= c; > elsif (sa = '1' and sb ='0') then > clear <= '0'; > count <= '1'; > if(Q = "0110") then > state_next <= d; > > end if; > end if; > > when d => > > if(Q = "0111") then > state_next <= a; > count <= '0'; > elsif(sb = '1') then > state_next <= d; > end if; > end case; > end process; > > process (state_reg) > begin > Ga <= '1'; Ya <= '0'; Ra <= '0'; > Gb <= '0'; Yb <= '0'; Rb <= '1'; > > case state_reg is > when a => > when b => > Ga <= '0'; > Ya <= '1'; > > when c => > Ya <= '0'; > Ra <= '1'; > Gb <= '1'; > > when d => > Gb <= '0'; > Yb <= '1'; > > end case; > > end process; > > end Behavioral; > ---------------------------------------------------------------------------------------------------------------------------------------------------------- First, I would stongly suggest you use numeric_std instead of std_logic_arith, especially when you're learning, since it's the accepted standard. Next, remember that at the start of simulation, all of your std_logic signal and output values are 'U', or unspecified. Any operation you perform where one of the operands is 'U' will most likely return 'U', so at some point you've got to give them a concrete value if you want anything to happen. Also, in a case statement, if you want to cover multiple cases, use "when a | b =>", not "when a => when b =>". That's the way it's done in C, not VHDL. These aren't all the problems, but hopefully this will set you on the right track.Article: 126754
Memory interface gererator 007 provides DDR1 SDRAM and DDR2 SDRAM memory interfaces for xilinx Virtex2, Virtex2P and Spartan3 FPGAs.It generates design files(rtl,sdc,ucf ) and documents (Timing,appnotes, user guide) in the usr folder for the selected options from the GUI. Following steps generate DDR1 SDRAM memory interface for, Components, 8 DQs per DQS, right side of V2P device to 72 bit data. * Select Memory type DDR1 by clicking the down arrow button. * Select the Components by checking the Component radio buttons. * Select the number of DQ bits per DQS 8 by checking the X8 radio buttons. * Select Family Virtex2P by clicking the down arrow button. * Select Part 2vp20ff1152 by clicking the down arrow button. * Select the Speed grade -6 by clicking the button. * Select the Frequency in MHz 200 by dragging the slider. * Select the number of controllers to 1 by clicking the down arrow button. * Select the banks for data and datastrobe by clicking the check box 2 and 3. * Select the banks for address & control by clicking the check box 6 and 7. * Enter the WASSO values for banks 2 and 3 by clicking the WASSO Table, if the WASSO values differ from default values. * Select the Data bits 72 by clicking the down arrow button. * To exclude Vrp/Vrn pins for memory interface check the "Reserve Vrp/Vrn pins " box. * From Menu "Options", HDL, select Verilog or VHDL. * From Menu "Options", Design, select Full controller or Physical layer with data or Physical layer with data, address and control. * Click on Show pins.The pins from the selected banks are displayed in the "Selected pins" listbox. To reserve some pins,double click it. Also click on "Read reserve pin ucf" button to input your constraint file so that the pins will not be used for memory interface. * Add button allows the user to add the pins back from the Reserved pins list for allocating to memory interface. * Hierarchy path provides the user for instantiating memory interface with other designs. * By default result files are stored in ../usr directoy. Result directory button allows the user to save the result files to a selected directory. * Click on "Generate design" to generate the design files.The files are created in usr directory. * Pin compatibility check button allows to generate UCF files across multiple devices. * Pin editor option allows the user to select the dq, dqs and no_dpin pins. Click on Show pins activates the Pin editor. <marek.kraft@gmail.com> wrote in message news:44abc58f-b167-4fb0-ba96-aac3f5f215c7@s19g2000prg.googlegroups.com... > Hello, > > I'd like to ask if there's a way to get the DDR RAM on the XUP V2Pro > board by Digilent up and running without using the PLB DDR controller? > I know here are a few designs for V2Pro, but I'm not an expert in > uding DRAM-s and haven't planned to become one (although I'm starting > to get an impression that without a significant amount of expertise I > won't be able to deal with the problem). The new MIG by Xilinx does > not support older parts, and the previous versions got me confused by > just looking at them. Anyway, it takes more than a headache to > discourage me from trying to get the memory to work, so I've dug out > the parameters of the DIMM module and the IC's mounted on it (I'm > using the 256MB Kingston module sold by Digilent, I've got it with the > board), checked it a few times, passed it to the editor and stumbled > upon the problem with the pins and banks settings (more dialogs, more > options...). I cannot work on this problem during the weekend, but I > just wanted to make sure if it is possible to create a working > controller for my board with the MIG? Does it require any fine-tuning > after implementation? Did anyone try it (and succeeded)? Are there > maybe other, more user-friendly, or maybe even ready-made, tested > soultions? Any help, guidance, directions are appreciated. I don't > want to spend too much time tackling this problem (although I'm aware > it might not be that easy). > > Kind regards.Article: 126755
Mark McDougall wrote:
>
> WARNING:Xst:647 - Input <vblank> is never used.
>
> But it clearly _is_ being used!?! Same for all the other signals that it's
> complaining about.
>
I've seen a number of cases where XST mistakenly optimizes
away necessary logic in working and tested code, causing symptoms
like you've described.
Once XST improperly trims one signal, the mistake often snowballs
as XST merrily optimizes away other useful things connected to it.
Tracking these problems down usually involves isolating one signal
that you KNOW should be used, then deleting everything else one
chunk at a time until the problem disappears or you're down to a
repeatable testcase. ( The RTL viewer is also a bit buggy, often not
properly displaying signals and wires )
Recently I've seen these problems in migrating old code
due to confusion on XST's part in a multibit comparison, such
as an address decode of a bus against a constant, when XST loses
track of whether one side or the other is signed/unsigned.
Adding a dummy '0' MSB in front of each term usually will
band-aid this particular problem away.
E.g., the following chip select decode will be mistakenly
optimized away in recent XST versions :
alias decode_field : std_logic_vector(3 downto 0) is address(15
downto 12);
constant CS2_ADDRESS : std_logic_vector(3 downto 0) := B"1010";
...
cs2_l <= '0' when ( io_enable = '1' ) AND ( decode_field =
CS1_ADDRESS )
else '1';
But only when:
- decode_field is an alias (signals work ok)
- the constant CS2_ADDRESS has the MSB set
- the old std_logic_signed package is used
( numeric_std, or just std_logic_unsigned."+" is ok)
have fun,
Brian
Article: 126756"tang" <tarangpatel2electric@gmail.com> wrote in message news:48da85be-c67e-479c-8b6c-3824f5e98ee9@d61g2000hsa.googlegroups.com... > hey guys i hope u can help me out... i want to design a simple traffic > light controller according to the 4 states shown in the code below. my > only problem is that my signal state_reg is not changing form one > state to another. this is because the counter i included in the the > code as a process is not working. green to yellow time wait is 30 sec > and yellow to red is 5 sec. my clock period will be 5 sec. so can > anyone help me out > Hey tang, You should try comp.lang.vhdl . There are a bunch of blokes over there who _really_ know how sensitivity lists work. Ask for Mike xor Jonathan orif Jim. They're among the best at homework. Tell them I sent you. HTH., Syms. p.s. These days, 'traffic light vhdl' is at 159000 Google hits. Adding lumberjack to the search gets you down to a more sensible 39. Only two worse than adding omg ponies. (Thanks to Ben J. for that insight!) Be sure to turn off 'safe search'.Article: 126757
On Sat, 1 Dec 2007 02:16:06 -0000, Symon wrote: >You should try comp.lang.vhdl . There are a bunch of blokes over there who >_really_ know how sensitivity lists work. Ask for Mike xor Jonathan orif >Jim. They're among the best at homework. Tell them I sent you. >HTH., Syms. Symon, you are A Very Bad Person. I can think of nations less tolerant and inclusive than ours where this sort of incitement to technical hatred could get you a stiff sentence (something along the lines of "This sentence is inflexible"?). >p.s. These days, 'traffic light vhdl' is at 159000 Google hits. Adding >lumberjack to the search gets you down to a more sensible 39. Only two worse >than adding omg ponies. [chokes on breakfast toast] Brilliant! -- 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: 126758
There are a large number of ways you could do this. Personally I'm not a get fan of next state, current state, style you use but it does have it's followers. Staying with what you have I would check the asychronous (combinatorial) processes have complete sensativity lists. Your clocked processes I would make sure all statements lie with the clock and reset statements. Personally I would have a counter that reloaded with values linked to the transitions of the state machine and taking a count value relevant to the state being entered. The counter then counts down to zero and then the next state transition. If you make your counter integer type you don't need extra numerical type libraries. John Adair Enterpoint Ltd. - Home of Craignells The obsolete DIL solution. On 30 Nov, 22:12, tang <tarangpatel2elect...@gmail.com> wrote: > hey guys i hope u can help me out... i want to design a simple traffic > light controller according to the 4 states shown in the code below. my > only problem is that my signal state_reg is not changing form one > state to another. this is because the counter i included in the the > code as a process is not working. green to yellow time wait is 30 sec > and yellow to red is 5 sec. my clock period will be 5 sec. so can > anyone help me out > > ------------------------------------------------------------------------------------------------------------------------------------------------------------ > library ieee; > use ieee.std_logic_1164.all; > use ieee.std_logic_arith.all; > use IEEE.std_logic_unsigned.all; > > entity TLC is > port( > clk,reset, sa, sb:in std_logic; > Ga, Ya, Ra, Gb, Yb, Rb:out std_logic > ); > end TLC; > > architecture Behavioral of TLC is > > type state_type is (a, b, c, d); > signal state_reg, state_next: state_type; > signal Pre_Q, Q: std_logic_vector(3 downto 0); > signal count, clear: std_logic; > > begin > > -- behavior describe the counter > process(clk, count, clear) > begin > if (clear = '0') then > Pre_Q <= Pre_Q - Pre_Q; > elsif (clk='1' and clk'event) then > if (count = '1') then > Pre_Q <= Pre_Q + 1; > end if; > end if; > Q <= Pre_Q; > end process; > > -- state register > > process(clk,reset) > begin > if(reset='0') then > state_reg <= a; > elsif (clk'event and clk='1') then > state_reg <= state_next; > end if; > end process; > > -- next state logic > > process(state_reg,Q,sa,sb) > begin > > case state_reg is > when a => > if(sa = '1' and sb = '0')then > state_next <= a; > elsif (sa = '0' and sb = '1') then > count <= '1'; > if(Q = "0110") then > state_next <= b; > end if; > end if; > > when b => > > if(Q = "0111") then > state_next <= c; > count <= '0'; > elsif(sa = '1') then > state_next <= b; > end if; > > when c => > if(sa = '0' and sb = '1') then > state_next <= c; > elsif (sa = '1' and sb ='0') then > clear <= '0'; > count <= '1'; > if(Q = "0110") then > state_next <= d; > > end if; > end if; > > when d => > > if(Q = "0111") then > state_next <= a; > count <= '0'; > elsif(sb = '1') then > state_next <= d; > end if; > end case; > end process; > > process (state_reg) > begin > Ga <= '1'; Ya <= '0'; Ra <= '0'; > Gb <= '0'; Yb <= '0'; Rb <= '1'; > > case state_reg is > when a => > when b => > Ga <= '0'; > Ya <= '1'; > > when c => > Ya <= '0'; > Ra <= '1'; > Gb <= '1'; > > when d => > Gb <= '0'; > Yb <= '1'; > > end case; > > end process; > > end Behavioral; > ----------------------------------------------------------------------------------------------------------------------------------------------------------Article: 126759
Believe it or not, I've already read it. I just wanted to ask if there are any surprises that might happen along the way. Sometimes things don't work exactly as they should. It's better to know about it earlier than after two weeks of why-the-hell-desn't-it-work. If anyone can give me such directions, has implemented successful controller on this board using MIG, or even points out an alternative solution that will work for me - that would be great. I am not working on it during the weekend, so I just thought it would be a good thing to ask. Kind regards, Marek. On 1 Gru, 00:53, "David Binnie" <td.bin...@blueyonder.co.uk> wrote: > Memory interface gererator 007 provides DDR1 SDRAM and DDR2 SDRAM memory > interfaces for xilinx Virtex2, Virtex2P and Spartan3 FPGAs.It generates > design files(rtl,sdc,ucf ) > and documents (Timing,appnotes, user guide) in the usr folder for the > selected options from > the GUI. > > Following steps generate DDR1 SDRAM memory interface for, Components, 8 DQs > per DQS, right side of V2P device to 72 bit data. > > * Select Memory type DDR1 by clicking the down arrow button. > > * Select the Components by checking the Component radio buttons. > > * Select the number of DQ bits per DQS 8 by checking the X8 radio buttons. > > * Select Family Virtex2P by clicking the down arrow button. > > * Select Part 2vp20ff1152 by clicking the down arrow button. > > * Select the Speed grade -6 by clicking the button. > > * Select the Frequency in MHz 200 by dragging the slider. > > * Select the number of controllers to 1 by clicking the down arrow button. > > * Select the banks for data and datastrobe by clicking the check box 2 and > 3. > > * Select the banks for address & control by clicking the check box 6 and 7. > > * Enter the WASSO values for banks 2 and 3 by clicking the WASSO Table, if > the WASSO values differ from default values. > > * Select the Data bits 72 by clicking the down arrow button. > > * To exclude Vrp/Vrn pins for memory interface check the "Reserve Vrp/Vrn > pins " box. > > * From Menu "Options", HDL, select Verilog or VHDL. > > * From Menu "Options", Design, select Full controller or Physical layer with > data or > Physical layer with data, address and control. > > * Click on Show pins.The pins from the selected banks are displayed in the > "Selected pins" > listbox. To reserve some pins,double click it. Also click on "Read reserve > pin ucf" > button to input your constraint file so that the pins will not be used for > memory interface. > > * Add button allows the user to add the pins back from the Reserved pins > list for allocating to > memory interface. > > * Hierarchy path provides the user for instantiating memory interface with > other designs. > > * By default result files are stored in ../usr directoy. Result directory > button allows the > user to save the result files to a selected directory. > > * Click on "Generate design" to generate the design files.The files are > created in usr directory. > > * Pin compatibility check button allows to generate UCF files across > multiple devices. > > * Pin editor option allows the user to select the dq, dqs and no_dpin pins. > Click on Show pins activates the Pin editor. > > <marek.kr...@gmail.com> wrote in message > > news:44abc58f-b167-4fb0-ba96-aac3f5f215c7@s19g2000prg.googlegroups.com... > > > Hello, > > > I'd like to ask if there's a way to get the DDR RAM on the XUP V2Pro > > board by Digilent up and running without using the PLB DDR controller? > > I know here are a few designs for V2Pro, but I'm not an expert in > > uding DRAM-s and haven't planned to become one (although I'm starting > > to get an impression that without a significant amount of expertise I > > won't be able to deal with the problem). The new MIG by Xilinx does > > not support older parts, and the previous versions got me confused by > > just looking at them. Anyway, it takes more than a headache to > > discourage me from trying to get the memory to work, so I've dug out > > the parameters of the DIMM module and the IC's mounted on it (I'm > > using the 256MB Kingston module sold by Digilent, I've got it with the > > board), checked it a few times, passed it to the editor and stumbled > > upon the problem with the pins and banks settings (more dialogs, more > > options...). I cannot work on this problem during the weekend, but I > > just wanted to make sure if it is possible to create a working > > controller for my board with the MIG? Does it require any fine-tuning > > after implementation? Did anyone try it (and succeeded)? Are there > > maybe other, more user-friendly, or maybe even ready-made, tested > > soultions? Any help, guidance, directions are appreciated. I don't > > want to spend too much time tackling this problem (although I'm aware > > it might not be that easy). > > > Kind regards.Article: 126760
L. Schreiber wrote: >> But now I'm getting an error (while implementation stage - don't know >> exactly at the moment). > > Ok, the error occured while translation in implementation phase. > >> I can't post the exact error message at the moment, but it will be >> given later if it's necessary. > > Here is the exact error message from the translation report: > > Reading NGO file "/home/schrl/ise/virtex2p/reconf_rs232/top.ngc" ... > > Applying constraints in "top.ucf" to the design... > ERROR:NgdBuild:753 - "top.ucf" Line 27: Could not find instance(s) > stat_r' in the design. To suppress this error specify the correct > instance name or remove the constraint. > > > I'm trying these first suggestions from M. Hicks and MH. > > thx Okay, last thursday i found the reason for this error. I have missablied the modular design flow. That's why your proposals haven't solved the problem. Anyway, thanks for your rapid replies. Now it works! :-)Article: 126761
<MikeShepherd564@btinternet.com> wrote in message news:p4tvk3t9idppelobu6kkk1i8j169pliter@4ax.com... > >I only ask first name & email address when joining, and then you can >>unsubscribe from the email list immediately if you want to - you get to >>keep >>the free lifetime membership so that you can watch the videos any time. > >>http://SuperSolderingSecrets.com > > I'm always suspicious when someone suggests that they have "secrets" > to reveal. > > Why do you want these details from those who visit your site? How > will you store them? How do we know that they are secure? Why do you > keep details for a "lifetime" after a user "unsubscribes"? > > There are lots of good videos about soldering available without > registration: > > http://www.howardelectronics.com/navigate/videoclips.html Thanks Mike, that's a great link. Definitely some good stuff there. Plus I understand what you are saying, but it's absolutely worthwhile checking out http://SuperSolderingSecrets.com videos too. If you are interested in soldering, there is some real value there with a unique perspective & original material from my personal experiences. I ask first name & email address because it is a membership site. The free membership is great for the QFP soldering info - that's why I posted on comp.arch.fpga. On the site there are also offers of upgrade for more videos, for people who do alot of soldering and are possibly looking for some extra techniques. Of course there is absolutely no obligation for anyone to ugrade.The free membership stuff is free. If members can get some good info & tips that they haven't seen before, then I am very happy & satisfied that I've passed on something useful. I treat all members & their email adresses with the greatest respect, care, and secure practices. Enjoy & cheers, Tony Burch http://SuperSolderingSecrets.comArticle: 126762
Hi, I am usign the Xilinx xapp058 design to program another device on the JTAG chain. In this design I download a xsvf file over a serial link and once it's done, the processor will play the xsvf to configure the other device. The xsvf file is played successfully. However, the done pin of the device under configuration doesn't go high and the device is not starting up. If I go to impact and read the status register of that device, I will get GHIGH = 1 meaning the configuration data is loaded correctly. And if I do a "verify", the device will then wake up and run. So it looks like I am lacking some startup instuctions in my xsvf file. Anyone has an idea how I can solve it? Thanks, YanArticle: 126763
Hello, I use SRAM Memory CY7C1386C. I downloaded datasheet and vhdl model from http://www.cypress.com/ I read that " Available speed grades are 250, 225, 200 and 167 MHz" Does it mean that ONLY these frequences are available? I have problem with write and read and I use 50Mhz clock.. Especially BURST-MODE is wrong. Is problem too litle clock or only too fast? Thanks CreateArticle: 126764
On Dec 1, 1:59 am, John Adair <g...@enterpoint.co.uk> wrote: > There are a large number of ways you could do this. Personally I'm not > a get fan of next state, current state, style you use but it does have > it's followers. > > Staying with what you have I would check the asychronous > (combinatorial) processes have complete sensativity lists. Your > clocked processes I would make sure all statements lie with the clock > and reset statements. > > Personally I would have a counter that reloaded with values linked to > the transitions of the state machine and taking a count value relevant > to the state being entered. The counter then counts down to zero and > then the next state transition. If you make your counter integer type > you don't need extra numerical type libraries. > > John Adair > Enterpoint Ltd. - Home of Craignells The obsolete DIL solution. > > On 30 Nov, 22:12, tang <tarangpatel2elect...@gmail.com> wrote: > > > > > > > hey guys i hope u can help me out... i want to design a simple traffic > > light controller according to the 4 states shown in the code below. my > > only problem is that my signal state_reg is not changing form one > > state to another. this is because the counter i included in the the > > code as a process is not working. green to yellow time wait is 30 sec > > and yellow to red is 5 sec. my clock period will be 5 sec. so can > > anyone help me out > > > ------------------------------------------------------------------------------------------------------------------------------------------------------------ > > library ieee; > > use ieee.std_logic_1164.all; > > use ieee.std_logic_arith.all; > > use IEEE.std_logic_unsigned.all; > > > entity TLC is > > port( > > clk,reset, sa, sb:in std_logic; > > Ga, Ya, Ra, Gb, Yb, Rb:out std_logic > > ); > > end TLC; > > > architecture Behavioral of TLC is > > > type state_type is (a, b, c, d); > > signal state_reg, state_next: state_type; > > signal Pre_Q, Q: std_logic_vector(3 downto 0); > > signal count, clear: std_logic; > > > begin > > > -- behavior describe the counter > > process(clk, count, clear) > > begin > > if (clear = '0') then > > Pre_Q <= Pre_Q - Pre_Q; > > elsif (clk='1' and clk'event) then > > if (count = '1') then > > Pre_Q <= Pre_Q + 1; > > end if; > > end if; > > Q <= Pre_Q; > > end process; > > > -- state register > > > process(clk,reset) > > begin > > if(reset='0') then > > state_reg <= a; > > elsif (clk'event and clk='1') then > > state_reg <= state_next; > > end if; > > end process; > > > -- next state logic > > > process(state_reg,Q,sa,sb) > > begin > > > case state_reg is > > when a => > > if(sa = '1' and sb = '0')then > > state_next <= a; > > elsif (sa = '0' and sb = '1') then > > count <= '1'; > > if(Q = "0110") then > > state_next <= b; > > end if; > > end if; > > > when b => > > > if(Q = "0111") then > > state_next <= c; > > count <= '0'; > > elsif(sa = '1') then > > state_next <= b; > > end if; > > > when c => > > if(sa = '0' and sb = '1') then > > state_next <= c; > > elsif (sa = '1' and sb ='0') then > > clear <= '0'; > > count <= '1'; > > if(Q = "0110") then > > state_next <= d; > > > end if; > > end if; > > > when d => > > > if(Q = "0111") then > > state_next <= a; > > count <= '0'; > > elsif(sb = '1') then > > state_next <= d; > > end if; > > end case; > > end process; > > > process (state_reg) > > begin > > Ga <= '1'; Ya <= '0'; Ra <= '0'; > > Gb <= '0'; Yb <= '0'; Rb <= '1'; > > > case state_reg is > > when a => > > when b => > > Ga <= '0'; > > Ya <= '1'; > > > when c => > > Ya <= '0'; > > Ra <= '1'; > > Gb <= '1'; > > > when d => > > Gb <= '0'; > > Yb <= '1'; > > > end case; > > > end process; > > > end Behavioral; > > ---------------------------------------------------------------------------------------------------------------------------------------------------------- Thanx for the solution. I was also thinking about making counter integer. Can you please elaborate on that? will it be like adding for loop till count reach to desired value and then perform the transition? thanx againArticle: 126765
On Nov 30, 6:16 pm, "Symon" <symon_bre...@hotmail.com> wrote: > "tang" <tarangpatel2elect...@gmail.com> wrote in message > > news:48da85be-c67e-479c-8b6c-3824f5e98ee9@d61g2000hsa.googlegroups.com...> hey guys i hope u can help me out... i want to design a simple traffic > > light controller according to the 4 states shown in the code below. my > > only problem is that my signal state_reg is not changing form one > > state to another. this is because the counter i included in the the > > code as a process is not working. green to yellow time wait is 30 sec > > and yellow to red is 5 sec. my clock period will be 5 sec. so can > > anyone help me out > > Hey tang, > You should try comp.lang.vhdl . There are a bunch of blokes over there who > _really_ know how sensitivity lists work. Ask for Mike xor Jonathan orif > Jim. They're among the best at homework. Tell them I sent you. > HTH., Syms. > p.s. These days, 'traffic light vhdl' is at 159000 Google hits. Adding > lumberjack to the search gets you down to a more sensible 39. Only two worse > than adding omg ponies. (Thanks to Ben J. for that insight!) Be sure to turn > off 'safe search'. thanx for the reply...Article: 126766
create wrote: > Hello, > I use SRAM Memory CY7C1386C. I downloaded datasheet and vhdl model from > http://www.cypress.com/ > > I read that " > Available speed grades are 250, 225, 200 and 167 MHz" > > Does it mean that ONLY these frequences are available? > > I have problem with write and read and I use 50Mhz clock.. > Especially BURST-MODE is wrong. > > Is problem too litle clock or only too fast? Neither one. These are fully synchronous devices, meaning they can operate at any frequency below their rated max. Your problem is somewhere else.Article: 126767
marek.kraft@gmail.com wrote: > Believe it or not, I've already read it. I just wanted to ask if there > are any surprises that might happen along the way. Sometimes things > don't work exactly as they should. It's better to know about it > earlier than after two weeks of why-the-hell-desn't-it-work. If anyone > can give me such directions, has implemented successful controller on > this board using MIG, or even points out an alternative solution that > will work for me - that would be great. I am not working on it during > the weekend, so I just thought it would be a good thing to ask. I took a look at using the mig generated core for DDR ram on a V2P. I discovered that in the user interface generated by that tool, some signals are clocked on the system clock, some on a 90 degree phase shifted clock, and some on a 180 degree phase shifted clock. Yikes! So much for an "easy" interface. I abandoned any attempt to use that core, and instead hacked on the plb ddr core, simply ignoring the plb interface and adding my own user interface instead.Article: 126768
Symon wrote: > p.s. These days, 'traffic light vhdl' is at 159000 Google hits. Adding > lumberjack to the search gets you down to a more sensible 39. farm_traffic takes it down to one. http://groups.google.com/groups/search?q=farm_traffic -- Mike TreselerArticle: 126769
Make sure you dont use the DCM and you have to complete the UCF, as for some reason Xilinx never produced a MIG tool for their V2P board (!) and then your nearly there, but ours doesn't work yet either so do keep in touch.Article: 126770
Chris Maryan wrote: > I thought this was rather cool, a timing diagram font: > http://www.pcserviceselectronics.co.uk/fonts/ > I've played around with it and it seems pretty good for most needs. Also very cool, thanks for the tip! cu, Sean -- My email address is only valid until the end of the month. Try figuring out what the address is going to be after that...Article: 126771
On Sat, 01 Dec 2007 11:33:23 -0800, Mike Treseler wrote: >farm_traffic takes it down to one. >http://groups.google.com/groups/search?q=farm_traffic Sorry Mike, it's two now - and this post will make it three :-) -- 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: 126772
"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message news:8ln3l3pdrhgq93k3qj5fj2u16ka5k6a7iq@4ax.com... > On Sat, 01 Dec 2007 11:33:23 -0800, Mike Treseler wrote: > >>farm_traffic takes it down to one. >>http://groups.google.com/groups/search?q=farm_traffic > > Sorry Mike, it's two now - and this post will make it three :-) > -- > Jonathan Bromley, Consultant > My gosh, you're right....it just keeps a growin, will it never end???? Can get it back down to 1 though by filtering out anything with the following words mike treseler wrote jonathan bromley http://groups.google.com/groups?as_q=farm_traffic&num=10&scoring=r&as_epq=&as_oq=&as_eq=Mike+Treseler+wrote+Jonathan+Bromley&as_ugroup=&as_usubject=&as_uauthors=&lr=&as_drrb=q&as_qdr=&as_mind=1&as_minm=1&as_miny=1981&as_maxd=1&as_maxm=12&as_maxy=2007&safe=off KJArticle: 126773
Hi, I find a strange problem relating to Quartus 7.2 and Modelsim 6.1g, web edition. For functional simulation, all is OK. For timing simulation, the component cannot be recognized by the testbench routine. I notice that in the work lib of Modelsim, the path sign is "\", not the same with the other's "/". Such as: C:\altera\72\qdesigns\... It should be: C:/altera/72/qdesigns/... I cannot find any menu to change the option in both Quartus and Modelsim. Could you tell me that? Thanks a lot.Article: 126774
On Nov 30, 4:46 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > KJ wrote: > > (snip) > > > Pipelining means simply to take a clock cycle (or more) to produce a result. > > What this essentially does is to spread out a computation so that part of it > > gets done in one clock cycle, another part gets done in some other clock > > cycle. > > This is especially convenient with FPGAs which usually have a FF at the > output of each LUT. > > > The reason you would do such a seemingly counterproductive thing is > > because sometimes the time it takes to do the entire calculation would mean > > that the system clock would have to slow down. By breaking the problem into > > smaller chunks, each chunk can be done faster. > > Assuming that you have a register, a big complicated block of logic, > followed by another register, pipelining allows you to speed up the > clock by adding additional registers inside the block of logic. > > One point, though. Pipelining allows an increased throughput, though > usually at increased latency. If you only want one it won't help > speed it up. It is when you want more than one that it helps. > The first result comes out after N (number of pipeline stages) clock > cycles. After that results come out each cycle. > > -- glen Thank you !
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