XILINX Webpack VHDL synthesis question (unnecessary MUX infered)

Hi group, When I am developing code for a hobby project, I find that XILINX webpack infers unnecessary MUX. I suspect that the MUX eats resource so I'd like to remove it to pack more function into the XC95144XL target. I am using the version 6.1. Here is the sample code (complete and compiles) and the synthesized schematic is posted at . I think ADDR_NEXT can be connected to D only and HOST_DATA can be connected to pre-set/clr only. Any idea? Thanks.

library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity busmaster is Port ( ADDR: out std_logic_vector(7 downto 0); ADDR_CLK_I: in std_logic; ADDR_NEXT: in std_logic_vector(7 downto 0); HOST_DATA: in std_logic_vector(7 downto 0); HOST_CSWR: in std_logic ); end busmaster; architecture Behavioral of busmaster is begin ADDR_UPDATE: process (HOST_DATA,HOST_CSWR,ADDR_CLK_I) begin -- process if HOST_CSWR = '0' then ADDR

Reply to
vax, 9000
Loading thread data ...

I agree 100%. The mux is pointless. In essence the mux combines the two sets of signals and the set/clear logic is demuxing them again. You DO need the and gates on the set/clear inputs since according to your code, HOST_DATA is a signal and not a constant and is only used when HOST_CSWR is '0'.

However, in a CPLD, I am not sure that the mux uses additional resources. The set/clear and gates will use some of the terms in the array, so I don't think any of the other terms will be available for other functions. Anyone know for sure?

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

vax, 9000, Cool Results. For some reason the synthesis tool got lost.

Some devices do not have an asynchronus set. Hence, they implement it with an asynchronous load and '1' on the data lines when asynchronous set is specified. However, if this was truely the case, then why not simplify the PRE input and not use the CLR input. Perhaps there is a bug in the synthesis part library.

Are you sure you really want an asynchronous load. Typically I only do asynchronous set and clears. All normal functionality is synchronous to clock.

Cheers, Jim

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
 Click to see the full signature
Reply to
Jim Lewis

XILINX webpack

I'd like to

synthesized

ADDR_NEXT can

pre-set/clr only.

As an experiment, what happens if you take HOST_DATA out of the sensitivity list? For a standard clocked process template I'd only expect to see asynchronous control signals and the clock in the sensitivity list, e.g.

addr_update:process(host_cswr, addr_clk_i) begin ...

regards Alan

--
Alan Fitch
Consultant
 Click to see the full signature
Reply to
Alan Fitch

This is an error I tried to tell Xilinx a long time ago. My FAE told me it will be fixed in version 7.1.

In the mean time you have to infer a FDCP primitive and attach your signals directly to the inputs.

Best regards Klaus Falser

Reply to
Klaus Falser

The result does not change (mux infered). Furthermore, I get a warming,

WARNING:Xst:819 - C:/busmaster/busmaster.vhd line 16: The following signals are missing in the process sensitivity list: HOST_DATA.

Thanks. VAX, 9000

Reply to
vax, 9000

That would not be correct in this case because the signal ADDR will change on a change of HOST_DATA while HOST_CSWR is low. So HOST_DATA does need to be in the sensitivity list. Normally the async control is just a clear or set so the data value is fixed, not a signal.

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

vax, 9000,

My first recommendation is to re-write it so the load is synchronous to clock: ADDR_UPDATE: process (HOST_DATA,HOST_CSWR,ADDR_CLK_I) begin -- process if ADDR_CLK_I'event and ADDR_CLK_I = '1' then if HOST_CSWR = '0' then ADDR

Reply to
Jim Lewis

HOST_DATA

is

Oh yes, sorry, brain failure :-)

Alan

--
Alan Fitch
Consultant
 Click to see the full signature
Reply to
Alan Fitch

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.