cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
983 Views
Registered: ‎05-23-2018

Internal signal pullup attribute (std_logic_vector) - VHDL on Artix7, Vivado 2018.2

Jump to solution

Hello,

I'm porting an old VHDL desing from a Spartan6 FPGA to an Artix 7 FPGA using Vivado 2018.2 tools.

In the design all hardware blocks are connected via a custom bus. The bus contains of a data bus and an event bus. The event bus signal is connected to each block via an INOUT port and can be used by the bus clients to generate events on which other clients will react. The logic of the event bus is low active and all the clients set the port to high impedance (others => 'Z'), while listening to the bus. Accordingly, they pull it to '0' if they generate an event.

Since the old design was done for a Spartan 6 FPGA, ISE tools where used. They supported an 'pullup' attribute for slv-signals. The bus signal is declared as follows:

signal event_bus : event_t; --event_t is a subtype of slv
attribute pullup of event_bus : signal is "yes";

I assume this assures, that the bus has a value of (others => '1') while no client puls its line to '0'. As far as my research goes, vivado does not seem to support the 'pullup' attribute for synthesis (UG901, page 231).

Does anyone know, if there might be an alternative solution to this when using the vivado tools?

My solution would be, to generate a piece of hardware, which pulls the bus to '1' when no client pulls it to '0'. Something like this:

process (clk) is
begin
  if rising_edge(clk) then
    for i in event_bus'range loop
      if event_bus(i) /= '0' then
        event_bus(i) <= '1';
      end if;
    end loop;
  end if;
end process;

I'm just not to sure what will happen to the bus signal when all clients put their port to 'Z'. Will it remain '0' after the last event generation, will it float? Would my solution even work? Alternatively I would have to implement state signals from each client to indicate if they released the event bus and pull it to '1' only if all clients released the bus.

If one of you has an idea for my problem, I'd be very thankful.

Thanks and have nice day :).

Regards,

Peter

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Visitor
Visitor
869 Views
Registered: ‎05-23-2018

Hello,

I got my questions answered in the meantime by our old supplier fortunately. Just in case someone finds himself asking the same questions, I'll post the answers here:


@gerp wrote:

I assume this assures, that the bus has a value of (others => '1') while no client puls its line to '0'. As far as my research goes, vivado does not seem to support the 'pullup' attribute for synthesis (UG901, page 231).   

 


I was correct about this. The pullup attribute adds an pullup to an internal signal. It is not possible for 7 series FPGAs.


@drjohnsmith wrote:

Very old chips had real internal tri state bus , and later tools if you defined a tri state bus, inferred a mux architecture for chips that did not have internal ti state.   

 


This was confirmed. On Spartan 3 for which this design was originally intented, the pullup for internal signals was possible, since an internal tri state bus existed. For Spartan 6 the ISE synthesis solved this problem otherwise. For 7 series FPGAs this compatibility does not exist, thus internal tristate busses should be avoided. I'll implement another solution now.


@gerp wrote:

 

    I'm just not to sure what will happen to the bus signal when all clients put their port to 'Z'. Will it remain '0' after the last event generation, will it float? 


It will float. This is why the internal pullup was needed for this implementation.

Thank you for all your replies. Have a nice day.

Regards

Peter

View solution in original post

0 Kudos
7 Replies
Highlighted
Visitor
Visitor
970 Views
Registered: ‎05-23-2018

By further thinking about it, i think that just the following assignment will solve my problem:

event_bus <= (others => 'H');

As far as I understand, this would generate a weak high / pullup on the signal, thus my problem is solved.

I'll try it out and edit this post, if it's successful.

EDIT:

This does not work in synthesis. I tried it and it is said so in UG901, p.170. Synthesis treats 'H' like a '1'.

I'm open for ideas :).

0 Kudos
Highlighted
Scholar
Scholar
934 Views
Registered: ‎08-01-2012

Is the "eventbus" an internal or external (via IO pin) ? FPGAs have not had internal tri-states for many years (like 15?) so using inouts internally is really not recommended.

Highlighted
Visitor
Visitor
904 Views
Registered: ‎05-23-2018

Hi,

thanks for your reply. Unfortunattely this "eventbus" is internally. It's not going outside to the PCB, so using the IO-Pullups is not possible.

As far as I know, our supplier (whoms code I'm working with) originally developed this for either Spartan 6 or even Spartan 3 (I know it runs on Spartan 6 but from some comments in the code I guess it was made for Spartan 3 originally). Maybe they hat internal tri-states?

Do you can think of an idea how to replicate this behavior maybe? My solution would be something like I posted originally, but having thougt about it, I would probably need an additional signal from all clients on the "bus" stating that they released the bus, so the external module can pull it to '1' once. I just fear the synthesis won't like this workaround and I will end up with a multiple driver error.

Thanks and regards

Peter

0 Kudos
Highlighted
Teacher
Teacher
899 Views
Registered: ‎07-09-2009
Was the bus intended to be 'tri state' internal.

Very old chips had real internal tri state bus , and later tools if you defined a tri state bus, inferred a mux architecture for chips that did not have internal ti state.

Could it be , that there is a control signal thats used , like a chip enable, so the bus is only used when its valid.


<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Highlighted
Visitor
Visitor
893 Views
Registered: ‎05-23-2018

@drjohnsmith wrote:
Was the bus intended to be 'tri state' internal.

Very old chips had real internal tri state bus , and later tools if you defined a tri state bus, inferred a mux architecture for chips that did not have internal ti state.

Could it be , that there is a control signal thats used , like a chip enable, so the bus is only used when its valid.



Hello,

thanks for your reply.

There is no chip enable unfortunately. Maybe I can explain a little more:

It's just a slv(15 downto 0) which connects all 'clients' via inout-ports. The devive the FPGA is controlling, is externally connected to another device, which can send configurations to the FPGA.

One of this configurations is the configuration of the use of this event bus. Each client can be configured to listen to one specific event line and to generate events on another event line. In practice (as far as I know), there is always only one client which generates an event on an eventline and multiple clients listening. For this use case the single lines would not need to be inout-ports, since only one client writes to a single line and the others listen. The reason it is designed this way, is that our supplier possibly wanted to have the flexibility of the event line configuration.

Looking at the source code of the device, which sends configurations to the FPGA, I don't think, that this flexibility is ever used. I guess, I'll just implement static eventlines between the hardwareblocks which depend on each others events and I'm done with it. This way the block which generates an event has an out-port and the listeners have an in-port.

Thanks for your replies. Have a nice day.

Regards

Peter

0 Kudos
Highlighted
Teacher
Teacher
880 Views
Registered: ‎07-09-2009

Just for completness, 

the other internal bus we used to do , was a "wired or"...

An output of a block is normaly zero.

    and you or all the outputs together ( bit 1 to bit 1, bit 2 to bit 2 etc )

provided all outputs are zero apart from the one you want, then you have a 'bus'.

     

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Visitor
Visitor
870 Views
Registered: ‎05-23-2018

Hello,

I got my questions answered in the meantime by our old supplier fortunately. Just in case someone finds himself asking the same questions, I'll post the answers here:


@gerp wrote:

I assume this assures, that the bus has a value of (others => '1') while no client puls its line to '0'. As far as my research goes, vivado does not seem to support the 'pullup' attribute for synthesis (UG901, page 231).   

 


I was correct about this. The pullup attribute adds an pullup to an internal signal. It is not possible for 7 series FPGAs.


@drjohnsmith wrote:

Very old chips had real internal tri state bus , and later tools if you defined a tri state bus, inferred a mux architecture for chips that did not have internal ti state.   

 


This was confirmed. On Spartan 3 for which this design was originally intented, the pullup for internal signals was possible, since an internal tri state bus existed. For Spartan 6 the ISE synthesis solved this problem otherwise. For 7 series FPGAs this compatibility does not exist, thus internal tristate busses should be avoided. I'll implement another solution now.


@gerp wrote:

 

    I'm just not to sure what will happen to the bus signal when all clients put their port to 'Z'. Will it remain '0' after the last event generation, will it float? 


It will float. This is why the internal pullup was needed for this implementation.

Thank you for all your replies. Have a nice day.

Regards

Peter

View solution in original post

0 Kudos