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
Hi, I know this is a dumb question, asking to decode some error directly. I got the following error, " Aggregate expression cannot be scalar type ieee.std_logic_1164.std_logic" and the code is "parrout(7 downto 0) => dataout_2(7 downto 0),".Article: 150176
On Dec 26, 7:33=A0am, Santosh <santos...@gmail.com> wrote: > Hi, > =A0I know this is a dumb question, asking to decode some error directly. > =A0I got the following error, > > " Aggregate expression cannot be scalar type > ieee.std_logic_1164.std_logic" > > and the code is > > "parrout(7 downto 0) =A0 =3D> =A0 dataout_2(7 downto 0),". Hi Santosh, First: when you provide a sample of code, please do include also the signal definition. Second: when reporting an error tell us also the compiler you are using. Third: some compilers do not allow the usage of ranges on left and right operands during assignments. If parrout is defined as 7 downto 0, you can try with defining a simple signal called dataout_2_7dt0 and write two separate assignments: dataout_2_7dt0 <=3D dataout_2(7 downto 0); ... parrout(7 downto 0) =3D> dataout_2_7dt0, In case parrout is not only 7 downto 0, but wider, you should use a temporary signal signal temp_parrout : std_logic_vector( N-1 downto 0 ); -- with N=3D the actual width of parrout temp_parrout <=3D "00000000" & dataout_2(7 downto 0); -- with "00000000" of the right dimension parrout =3D> temp_parrout, Good luck. MaurizioArticle: 150177
Hello, I'm trying to create an I2C master module in Verilog. I've never been able to successfully use inout's in Verilog and I'm still unsure why. I compiled my code and ran a test bench and I noticed the signals were at least changing; that is, the inout's seemed to be toggling. After this (although I still don't know if the module is conforming to the I2C bus protocol: baby steps) I decided to try it on my Altera DE2-115 board using the switches as inputs as I require an active high enable high to begin transmission on the bus. When I loaded my code, compiled it again, and installed it on the board I hooked up my logic analyzer and was excited to see... something: nothing. I'm confused why nothing at all showed up on my physical device while my test benches were producing logical values. I'm posting here for any advice from more experienced people. I've been trying to create this module for a while now and finally started work on it but am sort of at a loss as to where to begin my trouble shooting since I recently discovered how to create test benches in the first place; before that I would just load it onto my hardware lots of times. These are the only lines that deal with the inout-ness of the pins: inout sda; assign sda = (ena_sda)?sda_bit:`HIGH; assign sdaDataIn = (ena_sda)?`HIGH:sda; inout scl; assign scl = (ena_scl)?(pSCL?`HIGH:`LOW):`LOW; LOW is 0, while HIGH is 1'bZ. pSCL is a clock operating at the frequency for I2C transmission. Is this right the use of bidirectional pins or am I way off? If anyone wants more of the code just contact me; I don't want to flood this post with irrelevant information. It's worth noting that in the test-bench ena_scl and ena_sda were both working as expected which, in turn, made sda and scl show up correctly on the simulation. During my re-reading of this post I realized my physical test pin assignments had no connection to the I2C bus which meant there was no resistor to VCC on either of the lines. I fixed that; still have the exact same output! Thanks everyone. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150178
>Hello, I'm trying to create an I2C master module in Verilog. I've never >been able to successfully use inout's in Verilog and I'm still unsure why. >I compiled my code and ran a test bench and I noticed the signals were at >least changing; that is, the inout's seemed to be toggling. > >After this (although I still don't know if the module is conforming to the >I2C bus protocol: baby steps) I decided to try it on my Altera DE2-115 >board using the switches as inputs as I require an active high enable high >to begin transmission on the bus. When I loaded my code, compiled it again, >and installed it on the board I hooked up my logic analyzer and was excited >to see... something: nothing. > >I'm confused why nothing at all showed up on my physical device while my >test benches were producing logical values. I'm posting here for any advice >from more experienced people. I've been trying to create this module for a >while now and finally started work on it but am sort of at a loss as to >where to begin my trouble shooting since I recently discovered how to >create test benches in the first place; before that I would just load it >onto my hardware lots of times. > >These are the only lines that deal with the inout-ness of the pins: > >inout sda; > assign sda = (ena_sda)?sda_bit:`HIGH; > assign sdaDataIn = (ena_sda)?`HIGH:sda; > >inout scl; > assign scl = (ena_scl)?(pSCL?`HIGH:`LOW):`LOW; > >LOW is 0, while HIGH is 1'bZ. pSCL is a clock operating at the frequency >for I2C transmission. Is this right the use of bidirectional pins or am I >way off? If anyone wants more of the code just contact me; I don't want to >flood this post with irrelevant information. It's worth noting that in the >test-bench ena_scl and ena_sda were both working as expected which, in >turn, made sda and scl show up correctly on the simulation. > >During my re-reading of this post I realized my physical test pin >assignments had no connection to the I2C bus which meant there was no >resistor to VCC on either of the lines. I fixed that; still have the exact >same output! > >Thanks everyone. > > > >--------------------------------------- >Posted through http://www.FPGARelated.com > Not sure if you have done this but I usually in my designs create a seperate module with the IO buffers instantiated. So in my I2C design for a Xilinx FPGA I have the following. // SDA IO Buffer IOBUF U_sda( .I (1'b0), .IO (sda_io), .O (sda_rd), .T (sda_wr)); // SCL IO Buffer IOBUF U_scl( .I (1'b0), .IO (scl_io), .O (scl_rd), .T (scl_wr)); I then know that the buffers are correctly done. If your buffers are ok and you have external pullups then it should work. It may be worth if you have something like Chipscope to have a look and see what is going on inside the chip. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150179
On Dec 28, 9:03=A0am, "maxascent" <maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: > >Hello, I'm trying to create an I2C master module in Verilog. I've never > >been able to successfully use inout's in Verilog and I'm still unsure > why. > >I compiled my code and ran a test bench and I noticed the signals were a= t > >least changing; that is, the inout's seemed to be toggling. > > >After this (although I still don't know if the module is conforming to > the > >I2C bus protocol: baby steps) I decided to try it on my Altera DE2-115 > >board using the switches as inputs as I require an active high enable > high > >to begin transmission on the bus. When I loaded my code, compiled it > again, > >and installed it on the board I hooked up my logic analyzer and was > excited > >to see... something: nothing. > > >I'm confused why nothing at all showed up on my physical device while my > >test benches were producing logical values. I'm posting here for any > advice > >from more experienced people. I've been trying to create this module for > a > >while now and finally started work on it but am sort of at a loss as to > >where to begin my trouble shooting since I recently discovered how to > >create test benches in the first place; before that I would just load it > >onto my hardware lots of times. > > >These are the only lines that deal with the inout-ness of the pins: > > >inout sda; > > =A0 =A0assign sda =3D (ena_sda)?sda_bit:`HIGH; > > =A0 =A0assign sdaDataIn =3D (ena_sda)?`HIGH:sda; > > >inout scl; > > =A0 =A0assign scl =3D (ena_scl)?(pSCL?`HIGH:`LOW):`LOW; > > >LOW is 0, while HIGH is 1'bZ. pSCL is a clock operating at the frequency > >for I2C transmission. Is this right the use of bidirectional pins or am = I > >way off? If anyone wants more of the code just contact me; I don't want > to > >flood this post with irrelevant information. It's worth noting that in > the > >test-bench ena_scl and ena_sda were both working as expected which, in > >turn, made sda and scl show up correctly on the simulation. > > >During my re-reading of this post I realized my physical test pin > >assignments had no connection to the I2C bus which meant there was no > >resistor to VCC on either of the lines. I fixed that; still have the > exact > >same output! > > >Thanks everyone. > > >--------------------------------------- =A0 =A0 =A0 =A0 =A0 =A0 > >Posted throughhttp://www.FPGARelated.com > > Not sure if you have done this but I usually in my designs create a > seperate module with the IO buffers instantiated. So in my I2C design for= a > Xilinx FPGA I have the following. > > // SDA IO Buffer > IOBUF U_sda( > =A0 .I =A0(1'b0), > =A0 .IO (sda_io), > =A0 .O =A0(sda_rd), > =A0 .T =A0(sda_wr)); =A0 > > // SCL IO Buffer > IOBUF U_scl( > =A0 .I =A0(1'b0), > =A0 .IO (scl_io), > =A0 .O =A0(scl_rd), > =A0 .T =A0(scl_wr)); =A0 > > I then know that the buffers are correctly done. If your buffers are ok a= nd > you have external pullups then it should work. It may be worth if you hav= e > something like Chipscope to have a look and see what is going on inside t= he > chip. There's absolutely no reason to instantiate these sorts of buffers. The usual assignment statements work, and have worked for many years. All the instantiations do is make your code harder to understand and not portable. -aArticle: 150180
I'm using an older version of Xilinx ISE (V8.2.02i) and trying to create a project with a Microblaze which interfaces through a GPIO port to local combinatorial logic in the FPGA, not to the outside world through FPGA pins. I started a new project (top) from the ISE environment and defined my overall system pinout. I added a Microblaze processor as a component to the architecture of top and instantiated the Microblaze via a port map. I added the Microblaze .ucf file into the project. The only way I could get the project to correctly synthesize was to use the same literal names in my top entity defintions as were used in the Microblaze component definitions. The .ucf file that was created during the XPS Microblaze creation defines port pins for the peripheral functions. How can I change the interface pinout on a GPIO port to be directed to an internal set of logic instead of an FPGA pin to the outside world? For instance, if I wanted to use three pins from the outside world to drive a 3-to-8 decoder in the FPGA and then have the 8 outputs from the decoder drive 8 inputs of a GPIO port, could I do this? Do I absolutely have to include the Microblaze- generated .ucf file (which pre-defines all the pinouts for the GPIO ports) or can I define the .ucf for the top project from the ISE ? Does the newer version of the ISE 12.3 (or 12.4) have this same limitation on pinout allocation? Does anyone have a simple example that demonstrates how to do this?Article: 150181
>On Dec 28, 9:03=A0am, "maxascent" ><maxascent@n_o_s_p_a_m.n_o_s_p_a_m.yahoo.co.uk> wrote: >> >Hello, I'm trying to create an I2C master module in Verilog. I've never >> >been able to successfully use inout's in Verilog and I'm still unsure >> why. >> >I compiled my code and ran a test bench and I noticed the signals were a= >t >> >least changing; that is, the inout's seemed to be toggling. >> >> >After this (although I still don't know if the module is conforming to >> the >> >I2C bus protocol: baby steps) I decided to try it on my Altera DE2-115 >> >board using the switches as inputs as I require an active high enable >> high >> >to begin transmission on the bus. When I loaded my code, compiled it >> again, >> >and installed it on the board I hooked up my logic analyzer and was >> excited >> >to see... something: nothing. >> >> >I'm confused why nothing at all showed up on my physical device while my >> >test benches were producing logical values. I'm posting here for any >> advice >> >from more experienced people. I've been trying to create this module for >> a >> >while now and finally started work on it but am sort of at a loss as to >> >where to begin my trouble shooting since I recently discovered how to >> >create test benches in the first place; before that I would just load it >> >onto my hardware lots of times. >> >> >These are the only lines that deal with the inout-ness of the pins: >> >> >inout sda; >> > =A0 =A0assign sda =3D (ena_sda)?sda_bit:`HIGH; >> > =A0 =A0assign sdaDataIn =3D (ena_sda)?`HIGH:sda; >> >> >inout scl; >> > =A0 =A0assign scl =3D (ena_scl)?(pSCL?`HIGH:`LOW):`LOW; >> >> >LOW is 0, while HIGH is 1'bZ. pSCL is a clock operating at the frequency >> >for I2C transmission. Is this right the use of bidirectional pins or am = >I >> >way off? If anyone wants more of the code just contact me; I don't want >> to >> >flood this post with irrelevant information. It's worth noting that in >> the >> >test-bench ena_scl and ena_sda were both working as expected which, in >> >turn, made sda and scl show up correctly on the simulation. >> >> >During my re-reading of this post I realized my physical test pin >> >assignments had no connection to the I2C bus which meant there was no >> >resistor to VCC on either of the lines. I fixed that; still have the >> exact >> >same output! >> >> >Thanks everyone. >> >> >--------------------------------------- =A0 =A0 =A0 =A0 =A0 =A0 >> >Posted throughhttp://www.FPGARelated.com >> >> Not sure if you have done this but I usually in my designs create a >> seperate module with the IO buffers instantiated. So in my I2C design for= > a >> Xilinx FPGA I have the following. >> >> // SDA IO Buffer >> IOBUF U_sda( >> =A0 .I =A0(1'b0), >> =A0 .IO (sda_io), >> =A0 .O =A0(sda_rd), >> =A0 .T =A0(sda_wr)); =A0 >> >> // SCL IO Buffer >> IOBUF U_scl( >> =A0 .I =A0(1'b0), >> =A0 .IO (scl_io), >> =A0 .O =A0(scl_rd), >> =A0 .T =A0(scl_wr)); =A0 >> >> I then know that the buffers are correctly done. If your buffers are ok a= >nd >> you have external pullups then it should work. It may be worth if you hav= >e >> something like Chipscope to have a look and see what is going on inside t= >he >> chip. > >There's absolutely no reason to instantiate these sorts of buffers. >The usual assignment statements work, and have worked for many years. >All the instantiations do is make your code harder to understand and >not portable. > >-a > I dont see how it can be harder to understand unless you have no idea how an IO buffer works and if thats the case you shouldnt be doing FPGA design. All the Xilinx devices I have used use the same syntax for the common buffers and so the code should be fine across a wide number of devices. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150182
Hey Maurizio, I am sorry for incomplete question but thanks for your help I got the clue. :) Regards Santosh.Article: 150183
I have got a clock divider code as follows:
entity divClk8 is
Port ( CLK : in std_logic;
CLK_OUT : out std_logic);
end divClk8;
architecture Behavioral of divClk8 is
signal count : std_logic_vector (3 downto 0) := "1111";
signal reset : std_logic := '0';
begin
process(CLK)
begin
if(reset = '1') then
count <= "0000";
elsif(rising_edge(CLK)) then
count <= count + 1;
end if;
end process;
CLK_OUT <= count(3);
reset <= (count(3) and not(count(2))and not(count(1))and
not(count(0)));
end Behavioral;
But when I try to compile it using ModelSim I get the following error
-- No feasible entries for infix operator "+". Type error resolving
infix expression "+" as type ieee.std_logic_1164.std_logic_vector.
I didn't get what the error message says. A little word of advice
would be really helpful!
Regards
San
Article: 150184On Dec 29, 10:43=A0am, Santosh <santos...@gmail.com> wrote: > I have got a clock divider code as follows: > architecture Behavioral of divClk8 is > signal count : std_logic_vector (3 downto 0) :=3D "1111"; > signal reset : std_logic :=3D '0'; > > begin > process(CLK) > begin > if(reset =3D '1') then > count <=3D "0000"; > elsif(rising_edge(CLK)) then > count <=3D count + 1; > > But when I try to compile it using ModelSim I get the following error > > -- =A0No feasible entries for infix operator "+". Type error resolving > infix expression "+" as type ieee.std_logic_1164.std_logic_vector. > std_logic_vector signals do not have any math operators defined for them. A std_logic_vector is just a collection of bits with no numeric interpretation. To do what you want, you need to use a signal of type unsigned which is defined in the package 'ieee.numeric_std'. To fix up the code: - Add the line "use ieee.numeric_std.all" right after the line where you currently have "library ieee" - Change "signal count : std_logic_vector (3 downto 0)" to "signal count : unsigned (3 downto 0)" Kevin JenningsArticle: 150185
Check your used libraries. Modelsim don't find an implementation to add an integer 1 to a std_logic_vector. On Wed, 2010-12-29 at 07:43 -0800, Santosh wrote: > I have got a clock divider code as follows: >=20 > entity divClk8 is > Port ( CLK : in std_logic; > CLK_OUT : out std_logic); > end divClk8; >=20 > architecture Behavioral of divClk8 is > signal count : std_logic_vector (3 downto 0) :=3D "1111"; > signal reset : std_logic :=3D '0'; >=20 > begin > process(CLK) > begin > if(reset =3D '1') then > count <=3D "0000"; > elsif(rising_edge(CLK)) then > count <=3D count + 1; > end if; > end process; > CLK_OUT <=3D count(3); > reset <=3D (count(3) and not(count(2))and not(count(1))and > not(count(0))); > end Behavioral; >=20 >=20 >=20 > But when I try to compile it using ModelSim I get the following error >=20 > -- No feasible entries for infix operator "+". Type error resolving > infix expression "+" as type ieee.std_logic_1164.std_logic_vector. >=20 >=20 >=20 > I didn't get what the error message says. A little word of advice > would be really helpful! >=20 > Regards > SanArticle: 150186
On Dec 29, 8:43=A0am, Santosh <santos...@gmail.com> wrote: > I have got a clock divider code as follows: > > entity divClk8 is > =A0 =A0Port ( CLK : in std_logic; > =A0 =A0 =A0 =A0 =A0 CLK_OUT : out std_logic); > end divClk8; > > architecture Behavioral of divClk8 is > signal count : std_logic_vector (3 downto 0) :=3D "1111"; > signal reset : std_logic :=3D '0'; > > begin > process(CLK) > begin > if(reset =3D '1') then > count <=3D "0000"; > elsif(rising_edge(CLK)) then > count <=3D count + 1; > end if; > end process; > CLK_OUT <=3D count(3); > reset <=3D (count(3) and not(count(2))and not(count(1))and > not(count(0))); > end Behavioral; > > But when I try to compile it using ModelSim I get the following error > > -- =A0No feasible entries for infix operator "+". Type error resolving > infix expression "+" as type ieee.std_logic_1164.std_logic_vector. > > I didn't get what the error message says. A little word of advice > would be really helpful! > > Regards > San In addition to the responses you've had so far, don't you need to include the port for the reset line input and also include it in your process sensitivity list?Article: 150187
I noticed an odd thing happenning with Lattice EC VHDL project.... I have a register config1(7 downto 0) holding various configuration states, updated in a state machine which only gets clocked at certain times (i.e. not continuous). All bits of this register are set to 0 on powerup (implicitly, as per VHDL default). I then assign a couple of pins to output a bit in this register for debug purposes pin112<= not config1(5); pin109<= config1(5); However on powerup, both of these pins are low. When the config1 register is subsequently clocked, the pins then reflect the true and inverted states as you'd expect. The compile report does appear to suggest it is inferring latches for these signals. TN1008 suggests use of else to avoid inferred latches, so I also tried pin112<='0' when config1(5)='1' else '1'; with the same result - it is still inferring a latch. I've worked around this by explicitly latching the signals from a continuous clock, but how would I force it to NOT infer the latch, and use a simple combinatorial inverter from the register to the pin?Article: 150188
Le 29/12/2010 16:43, Santosh a écrit : > I have got a clock divider code as follows: > > entity divClk8 is > Port ( CLK : in std_logic; > CLK_OUT : out std_logic); > end divClk8; > > architecture Behavioral of divClk8 is > signal count : std_logic_vector (3 downto 0) := "1111"; > signal reset : std_logic := '0'; > > begin > process(CLK) > begin > if(reset = '1') then > count<= "0000"; > elsif(rising_edge(CLK)) then > count<= count + 1; > end if; > end process; > CLK_OUT<= count(3); > reset<= (count(3) and not(count(2))and not(count(1))and > not(count(0))); > end Behavioral; > > > > But when I try to compile it using ModelSim I get the following error > > -- No feasible entries for infix operator "+". Type error resolving > infix expression "+" as type ieee.std_logic_1164.std_logic_vector. What do you plan to do with your divided clock output ? It will be a short glith-like pulse that will be very dependent on many things (mainly temperature) that won't be very usable. NicolasArticle: 150189
On Dec 29, 1:00=A0pm, Mike Harrison <m...@whitewing.co.uk> wrote: > I noticed an odd thing happenning with Lattice EC VHDL project.... > > I have =A0a register config1(7 downto 0) holding various configuration st= ates, updated in a state > machine which only gets clocked at certain times (i.e. not continuous). > > All bits of this register are set to 0 =A0on powerup (implicitly, as per = VHDL default). > > I then assign a couple of pins to output a bit in this register for debug= purposes > > pin112<=3D not config1(5); > pin109<=3D config1(5); > > However on powerup, both of these pins are low. When the config1 register= is subsequently clocked, > the pins then reflect the true and inverted states as you'd expect. > > The compile report does appear to suggest it is inferring latches for the= se signals. > > TN1008 suggests use of else to avoid inferred latches, so I also tried > > pin112<=3D'0' when config1(5)=3D'1' else '1'; > > with the same result - it is still inferring a latch. > > I've worked around this by explicitly =A0latching the signals from =A0a c= ontinuous clock, but how would > I force it to NOT infer the latch, and use a simple combinatorial inverte= r from the register to the > pin? If you are making the assignment to config1 in a clocked process I expect you are omitting an explicit reset assignment. I'm not sure what logic is generated under these conditions, or why, but I always include an assignment to registers for the reset state. The only way I can think that the two outputs would be in the states you describe is if the register is being replicated and pushed into the IOBs. Each of the FFs might be reset by the power on reset, assuming a correct value after being clocked. When you say your state machine is not clocked continuously, do you mean you are gating the clock? Or are you enabling the clock? You might want to simplify your code to a test case and if the problem remains, post it here. If the problem goes away try adding in more of the actual code until it breaks. Otherwise, maybe you could post your code for us to read. RickArticle: 150190
> I am sorry for incomplete question but thanks for your help I got the > clue. Great! You're welcome. Happy new year! MaurizioArticle: 150191
Hi,
I am designing a very simple cw keyer, and I am wondering why some
timings in reset signal is triggering timing violations.
My problem is that apparently symmetrical FSMs get warnings on one
instance while the other not.
I got timing violations when reset duration is, for example 60ns or
100ns in the testbench:
...
// Initialize Inputs
fx2_clk = 0;
paddledot <= 1'b1;
paddledash = 1'b1;
resetpin = 1;
// Wait 100 ns for global reset to finish
#60;
resetpin = 0;
60 or 100ns are exactly on the raising edge of the feeded fx2_clk (40ns
period).
I got these warnings:
WARNING:Simulator:29 - at 63.358 ns: Warning: Timing violation in
/test002/uut/dashstate_FSM_FFd1/ $recrem<recovery>( RST:62.893 ns,
CLK:63.358 ns,991.000 ps)
WARNING:Simulator:29 - at 63.370 ns: Warning: Timing violation in
/test002/uut/morsestate_FSM_FFd1/ $recrem<recovery>( RST:62.958 ns,
CLK:63.370 ns,991.000 ps)
My question is: why I got the warning on dashstate and not on dotstate?
They are debouncers for the dot and dash paddle inputs and they are
identical.
I have similar problems on another FSM:
...
always @(posedge fx2_clk or posedge resetpin )
if (resetpin)
begin
// cwkeyer <= 1'b0;
// wpm_tick_trigger <= 1'b0;
morsestate <= 4'b0000;
end
else
case (morsestate)
4'b0000: begin
// init state
cwkeyer <= 1'b0;
wpm_tick_trigger <= 1'b0;
morsestate <= 4'b0001;
end
...
but not on this, that looks similar to me:
...
// WPM timer - fixed at 12 WPM at the moment
always @(posedge fx2_clk or posedge resetpin)
if (resetpin)
begin
// wpm_tick_elapsed <= 1'b0;
// cntwpm <= 24'b0;
wpmstate <= 4'b0000;
end
else
case (wpmstate)
4'b0000: begin
wpm_tick_elapsed <= 1'b0;
cntwpm <= 24'b0;
wpmstate <= 4'b0001;
end
...
The other question is: how is supposed async reset to be properly
handled? Should I ignore the warnings?
WebISE is 10.1
TIA,
Giuseppe Marullo
PS: some snipplets of code:
...
reg [3:0] dotstate;
reg [3:0] dashstate;
...
always @(posedge fx2_clk or posedge resetpin)
if (resetpin)
begin
//dashout <= 1'b0;
//cntdash <= 4'b0;
dashstate <= 4'b0000;
end
else
case (dashstate)
4'b0000: begin
dashout <= 1'b0;
cntdash <= 4'b0;
dashstate <= 4'b0001;
end
4'b0001: begin
if (paddledash == 1'b0)
dashstate <= 4'b0010;
else
dashout <=1'b0;
end
4'b0010: begin
if (paddledash == 1'b0)
begin
cntdash <= cntdash + 1'b1;
end
if (cntdash == 4'b011)
begin
dashout <= 1'b1;
cntdash <= 4'b0;
dashstate <= 4'b0001;
end
end
endcase
always @(posedge fx2_clk or posedge resetpin)
if (resetpin)
begin
// dotout <= 1'b0;
// cntdot <= 4'b0;
dotstate <= 4'b0000;
end
else
case (dotstate)
4'b0000: begin
dotout <= 1'b0;
cntdot <= 4'b0;
dotstate <= 4'b0001;
end
4'b0001: begin
if (paddledot == 1'b0)
dotstate <= 4'b0010;
else
dotout <=1'b0;
end
4'b0010: begin
if (paddledot == 1'b0)
begin
cntdot <= cntdot + 1'b1;
end
if (cntdot == 4'b011)
begin
dotout <= 1'b1;
cntdot <= 4'b0;
dotstate <= 4'b0001;
end
end
endcase
...
Article: 150192Overloading will allow you to add integers like 1 (such as for basic counters) to your std_logic_vector's. One of the IEEE libraries will allow you to do this if you include the right one. Don't remember which one off top of my head. Some other observations: - You are missing a reset input. - You don't need to include reset into sensitivity list if you are treating it synchronously. - If you maintain std_logic_vector(3 downto 0) type OR use integer of "range 0 to 3" there is no need to reset counter if you intend to rollover at max (all 1's) value. JohnArticle: 150193
XST Fails 2D array wild card sensitivity list
XST fails the following Verilog (similar HDL) where other synthesizers /
compilers do not?
wire [15:0] x [0:15];
wire [15:0] y [0:15];
wire [15:0] z;
wire [15:0] xo [0:15];
wire [15:0] yo [0:15];
always @(*) begin
if (cnt < 8) begin
xo[cnt] = x[cnt];
yo[cnt] = y[cnt];
end
else begin
xo[cnt] = z;
yo[cnt] = 16’b0;
end
end
HDL similar to the above fails in XST but synthesizes / compiles correctly
in all of the following
Icarus Verilog
Modelsim
Ncsim
Cadence RTL Compiler
Synplify Pro
Altera Quartus
Does XST simply not support this?
Or is the above not defined by the Verilog 1364 and the others just support
it anyway? Or is there an XST switch that I am missing?
chris
---------------------------------------
Posted through http://www.FPGARelated.com
Article: 150194>Hello, I'm trying to create an I2C master module in Verilog. [snip] >These are the only lines that deal with the inout-ness of the pins: > >inout sda; > assign sda = (ena_sda)?sda_bit:`HIGH; > assign sdaDataIn = (ena_sda)?`HIGH:sda; > >inout scl; > assign scl = (ena_scl)?(pSCL?`HIGH:`LOW):`LOW; > [snip] > assign sda = (sda_bit == 0) ? 1'b0 : 1'bz; assign sdaDataIn = sda; Only drive the signal low, tri-state IOBUF. This assumes sda is the IOBUF (top-level port) and sda_bit is the internal sdaDataOut signal. --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150195
>XST Fails 2D array wild card sensitivity list > > >XST fails the following Verilog (similar HDL) where other synthesizers / >compilers do not? > >wire [15:0] x [0:15]; >wire [15:0] y [0:15]; >wire [15:0] z; > >wire [15:0] xo [0:15]; >wire [15:0] yo [0:15]; > > >always @(*) begin > if (cnt < 8) begin > xo[cnt] = x[cnt]; > yo[cnt] = y[cnt]; > end > else begin > xo[cnt] = z; > yo[cnt] = 16’b0; > end >end > > >HDL similar to the above fails in XST but synthesizes / compiles correctly >in all of the following > > Icarus Verilog > Modelsim > Ncsim > Cadence RTL Compiler > Synplify Pro > Altera Quartus > >Does XST simply not support this? >Or is the above not defined by the Verilog 1364 and the others just support >it anyway? Or is there an XST switch that I am missing? > > >chris > > >--------------------------------------- >Posted through http://www.FPGARelated.com > I think your problem may be the array indexing. I had a similar problem and had to use an assign statement to fix it. Jon --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150196
The spam in Google groups has only gotten worse lately and there seems to be no end in sight. This group is getting hard to find the real posts in and some of the other groups are just plain unusable with five or ten spam messages to every real message. Rather than to add spam filters as most newsgroup access providers do, Google has invented an entirely new interface with an entirely new look, with the ability to flag a post as spam (or otherwise inappropriate) and it is hidden from your view. That would be great, except that the new interface sucks compared to the old one. Maybe it is just that I'm used to the old one, but I have tried the new one in one of the groups I access and I don't seem to be liking it any more than when I first saw it. For a company that is so good at search engines, why can't they understand anything about how newsgroups should work? RickArticle: 150197
>The spam in Google groups has only gotten worse lately and there seems >to be no end in sight. This group is getting hard to find the real >posts in and some of the other groups are just plain unusable with >five or ten spam messages to every real message. > [snip] > I use a usenet (thunderbird) but also use dsprelated / fpgarelated for the comp.fpga and comp.dsp. I don't notice much spam through these web interfaces. chris --------------------------------------- Posted through http://www.FPGARelated.comArticle: 150198
Hi, There is a Xilinx answer record that addresses this issue: http://www.xilinx.com/support/answers/20391.htm Thanks, EvgeniArticle: 150199
>> On Dec 28, 9:03=A0am, "maxascent" wrote: > I dont see how it can be harder to understand unless you have no idea how > an IO buffer works and if thats the case you shouldnt be doing FPGA design. What if I am using an Altera device? Your scheme does not work at all. Andy's works either way. -- Mike Treseler
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