Proper Platform Definition
I've got a custom platform I'm trying to create, but I'm a little confused
about the best practices.
I'm looking at the normal OpenCPI repository as well as this E310
repository for reference:
https://github.com/opencpi/av.bsp.e310
In general, I see that platforms define devices which can be instantiated
in configurations. So the platform will have all the device mappings, and
the configurations actually instantiate a real device worker.
For the E310 repository, an e310_conn is made as an abstraction for a slot
on the E310 even through there are no slots, really. This is very similar
to my situation as everything is soldered to the board but possibly not
populated.
Currently, I've just been defining the devices and signals for the
platform, but no slot. Is this all a matter of personal preference, or is
it better to make a slot even though it isn't actually a slot?
Lastly, I have configurations which have LVDS signals defined as outputs.
If I want to drive those signals to safe levels if those devices are not
instantiated, what's best practices here? The Xilinx tools need those
pairs driven by an OBUFDS, but if that device isn't instantiated that
primitive won't get instantiated. Should this be a property of the device,
then, to say if it's actually doing something or if it's just driving
nothing?
I tend to see a lot regarding differential pairs in the development guides,
but not so much used in practice except for the ml605 platform which seems
to be a bit older. Hence all the questions.
Thanks,
Brian
HI Brian,
Good questions as usual.
The "slot or no slot" decision should come down to whether there are
truly alternative hardware subsystems that you need to support.
Normally that is a true, standards-based slot like FMC, but another
interesting case is the adrv9361 (not released yet), which has various
"motherboards" that provide different hardware environments for the
basic "platform" board.
I think your case, where there are different "soldered/populated"
configurations of your basic platform, could plausibly use the slot
paradigm too, since it would allow you to correctly specify the
different hardware option configurations.
(although if every device is optional, that can lead to a combinatorial
explosion of physical configurations).
I'm not sure about the E310 as an example since I do not know whether
there are ever likely to be alternative "cards" for that physical "slot".
The "tieoff" logic for differential signals not driven when devices are
not instanced has some issues about differential outputs that will be
fixed in 1.7.
Normally unused signals are simply driven to '0', but differential ones
IIRC are not driven correctly in this case.
Jim
On 1/21/20 10:23 PM, Brian Padalino wrote:
I've got a custom platform I'm trying to create, but I'm a little confused
about the best practices.
I'm looking at the normal OpenCPI repository as well as this E310
repository for reference:
https://github.com/opencpi/av.bsp.e310
In general, I see that platforms define devices which can be instantiated
in configurations. So the platform will have all the device mappings, and
the configurations actually instantiate a real device worker.
For the E310 repository, an e310_conn is made as an abstraction for a slot
on the E310 even through there are no slots, really. This is very similar
to my situation as everything is soldered to the board but possibly not
populated.
Currently, I've just been defining the devices and signals for the
platform, but no slot. Is this all a matter of personal preference, or is
it better to make a slot even though it isn't actually a slot?
Lastly, I have configurations which have LVDS signals defined as outputs.
If I want to drive those signals to safe levels if those devices are not
instantiated, what's best practices here? The Xilinx tools need those
pairs driven by an OBUFDS, but if that device isn't instantiated that
primitive won't get instantiated. Should this be a property of the device,
then, to say if it's actually doing something or if it's just driving
nothing?
I tend to see a lot regarding differential pairs in the development guides,
but not so much used in practice except for the ml605 platform which seems
to be a bit older. Hence all the questions.
Thanks,
Brian
On Wed, Jan 22, 2020 at 7:52 AM James Kulp jek@parera.com wrote:
HI Brian,
Good questions as usual.
The "slot or no slot" decision should come down to whether there are
truly alternative hardware subsystems that you need to support.
Normally that is a true, standards-based slot like FMC, but another
interesting case is the adrv9361 (not released yet), which has various
"motherboards" that provide different hardware environments for the
basic "platform" board.
Understandable.
I think your case, where there are different "soldered/populated"
configurations of your basic platform, could plausibly use the slot
paradigm too, since it would allow you to correctly specify the
different hardware option configurations.
(although if every device is optional, that can lead to a combinatorial
explosion of physical configurations).
Got it. Thanks. I'll take it into consideration. I appreciate the
pointers.
I'm not sure about the E310 as an example since I do not know whether
there are ever likely to be alternative "cards" for that physical "slot".
The "tieoff" logic for differential signals not driven when devices are
not instanced has some issues about differential outputs that will be
fixed in 1.7.
Normally unused signals are simply driven to '0', but differential ones
IIRC are not driven correctly in this case.
Right, plus there is no instantiation of the differential buffer.
When it comes to timeframes, do you know when the next releases are
scheduled? I'm working from github on v1.5.1. I've read on the mailing
list regarding 1.6 and 1.7 and moving over to gitlab. Is there a schedule
that can be shared?
Thanks,
Brian