Physical UI Connection in Simulink

[dack-fe]

Provide a way to define buttons, LEDs, and switches in Frost Autogen an control them from Frost Edge UI

[fe-wickham]

Design thoughts on this:

• Implement as a special register in model.json
• Would require minimal automatic updates to the top level VHDL file for the project
  • Connecting new Platform Designer exported conduit to existing signal: led => LED(0),
• Would require updating Avalon wrapper to have a new signal coming out of it and connect it appropriately within the wrapper
• Would require updating _hw.tcl ip core to have the updated interface of the Avalon wrapper

[tvannoy]

@fe-wickham that sounds like a reasonable approach.

Since there are multiple LEDs, buttons, etc., how would we define which one to hook up to, e.g. led => LED(0) or led => LED(1)? Would there be a predefined list of special registers for each hardware platform?

Most of the required updates don't seem like too much work. There might be some details to work out in terms of having output/read-only "registers" in the Simulink model, though.

This approach seems like the path of least resistance, though I am still interested in the idea of utilizing HDL Coder's built-in "custom hardware target" functionality for these sort of features (of course doing so entails much more refactoring of our current framework).

[fe-wickham]

Would there be a predefined list of special registers for each hardware platform?

Well sort of. If the user is interacting with hardware, there is no way to get around them needing to specify exactly what they want to interact with so I would think it best to use either the pin assignment and we parse things to figure out the signal or they can provide the signal defined in the top level VHDL file.

utilizing HDL Coder's built-in "custom hardware target" functionality

I don't think that can actually be justified. The work is extremely high and moves us from Matlab/Simulink just being a frontend to generate VHDL and something much more integral to the rest of the process. While its no walk in the park to implement, what I have pointed out is it would be nice to support Xilinx and in doing so we can easily add another frontend because Xilinx has a C based HLS for their boards.

There might be some details to work out in terms of having output/read-only "registers" in the Simulink model, though.

There is some real effort for a good implementation on the Linux side, but for output only at the VHDL level it is pretty trivial. Have a matching output in the dataplane and the Avalon address just needs to have the line for writing removed.

[tvannoy]

Well sort of. If the user is interacting with hardware, there is no way to get around them needing to specify exactly what they want to interact with so I would think it best to use either the pin assignment and we parse things to figure out the signal or they can provide the signal defined in the top level VHDL file.

True. That seems reasonable. Perhaps the register's "value" would be the pin assignment or the signal name (and those are predefined, of course.)

The work is extremely high and moves us from Matlab/Simulink just being a frontend to generate VHDL and something much more integral to the rest of the process

When you frame it that way, I agree. I've always been a fan of having the option to support other ways of generating VHDL.

it would be nice to support Xilinx

Indeed. This is possible with HDL Coder, though. One of the biggest hurdles (on the HDL side) for us supporting Xilinx is that we are not using AXI interfaces.

in doing so we can easily add another frontend because Xilinx has a C based HLS for their boards

Intel has a C-based HLS as well (and OpenCL, too, I think). It would be really nice to have the option to support the vendor HLS tools in the future, as end users are potentially more likely to have access to those than to all of the MATLAB/Simulink toolboxes we currently use.

There is some real effort for a good implementation on the Linux side, but for output only at the VHDL level it is pretty trivial. Have a matching output in the dataplane and the Avalon address just needs to have the line for writing removed.

Yeah, for sure. The VHDL and TCL parts are trivial.

---

I agree with where you want to go with this. I think keeping the option to support other code generators (or even hand-written code :astonished:) is something we should strive for.