11-20-2019, 10:25 PM
Hello,
First of all, we do not have a 'better' internal PULPissimo system internally, the GitHUb release is the one we are also using for our projects. What happens is that once we have an ASIC project, then we have an internal version that has a process specific instantiation (i.e. for GF22FDX) which contains memory cuts, I/O pads, clock gating cells etc that are specific to that technology. Until now, we do not have a way to release these technology specific components (NDAs we have signed do not allow us to release them). But the RTL code base is still the same, and any issues we find, fixes we make are contributed to the main branch.
Generally we do not optimize our code for FPGA targets. In your questions
1) Refers to one implementation we use for the FPGA board (there is a clock on the board that is available)
2) Is the one that usually ends up how we use it in an ASIC. We use a slow XTAL oscillator externally (32kHz) and have our own (technology mapped) FLL that can be programmed to generate the clocks we need inside. (Similarly we can also not release the FLL openly.. yet..)
I have to check the code, but I'm pretty sure even in the 32kHz ASIC/FLL configuration we add a bypass mux so that the reference clock goes into the system directly.
You can change and adapt the clocking according to your needs, the domains are clearly separated and should be easily manageable. What you describe should work fine. We know of people that have done some simple optimizations so that the code maps 'better' to a given FPGA target. Note that, it could get tedious to update the optimized code whenever the generic code gets a fix or improvement.
I hope this helps
First of all, we do not have a 'better' internal PULPissimo system internally, the GitHUb release is the one we are also using for our projects. What happens is that once we have an ASIC project, then we have an internal version that has a process specific instantiation (i.e. for GF22FDX) which contains memory cuts, I/O pads, clock gating cells etc that are specific to that technology. Until now, we do not have a way to release these technology specific components (NDAs we have signed do not allow us to release them). But the RTL code base is still the same, and any issues we find, fixes we make are contributed to the main branch.
Generally we do not optimize our code for FPGA targets. In your questions
1) Refers to one implementation we use for the FPGA board (there is a clock on the board that is available)
2) Is the one that usually ends up how we use it in an ASIC. We use a slow XTAL oscillator externally (32kHz) and have our own (technology mapped) FLL that can be programmed to generate the clocks we need inside. (Similarly we can also not release the FLL openly.. yet..)
I have to check the code, but I'm pretty sure even in the 32kHz ASIC/FLL configuration we add a bypass mux so that the reference clock goes into the system directly.
You can change and adapt the clocking according to your needs, the domains are clearly separated and should be easily manageable. What you describe should work fine. We know of people that have done some simple optimizations so that the code maps 'better' to a given FPGA target. Note that, it could get tedious to update the optimized code whenever the generic code gets a fix or improvement.
I hope this helps
Visit pulp-platform.org and follow us on twitter @pulp_platform