Interface for determining package pins #38
Conversation
robtaylor
force-pushed
the
packagepins
branch
from
7647f03 to
7b415ce
Compare
|
chipflow_lib/platforms/utils.py
Outdated
| @@ -114,6 +114,16 @@ def BidirPinSignature(width, **kwargs): | |||
| PinList = List[Pin] | |||
| Pins = Union[PinSet, PinList] | |||
|
|
|||
| class PowerPins(enum.Enum): | |||
There was a problem hiding this comment.
We probably at least want to split IO vs core here
There was a problem hiding this comment.
good point. what sort of information does the IO power pins need?
There was a problem hiding this comment.
I think this is what Serge brought up on Element already a few days ago. Basically right now we have all the IO in one bank with no breaker cells used, so we just have IOVdd/IOVss that apply to all IO pins. But eventually we want to have multiple groups of IO pins (potentially including analog) in seperate banks, each associated with its own one or more IO power and ground pins.
There was a problem hiding this comment.
Maybe we introduce the idea of a power domain? Might be too much to resolve properly at this point without concrete use cases :/
There was a problem hiding this comment.
Power domain could be good idea, but domains could have relations, or even connected inside. I think better to start with two related to each other power domains, with specifying one for the Core and another for IO.
There was a problem hiding this comment.
I think this has to be further split up in different domains for core and different domains for IO. You will have breaker IO cells that will break the core and/or the IO supply/ground rings in the IO ring.
Multiple core power domains will also need support from Amaranth to know which logic has to be in which power domain.
An anlog input does not necessarily need to be in separate IO power domain but typically one wants to have a separate power domain for the analog block connected to the analog input to isolate analog block from the digital or IO switching noise on the vdd/gnd or iovdd/iognd signals.
chipflow_lib/platforms/utils.py
Outdated
|
|
||
| @property | ||
| @abc.abstractmethod | ||
| def heartbeat(self) -> Dict(int, Pin): |
There was a problem hiding this comment.
The clock in some cases comes as two pins close to each other to be connected to XTAL.
There was a problem hiding this comment.
hmm, good point. Is that a config option to generate a oscillator?
There was a problem hiding this comment.
There was a problem hiding this comment.
Currently we have nothing to specify use of XTAL, this needs to be added somehow.
There was a problem hiding this comment.
The clock in some cases comes as two pins close to each other to be connected to XTAL.
If you have external crystal you will need a crystal oscillator analog block on the chip. The actual clock will then be an output of this oscillator.
There was a problem hiding this comment.
What also can happen is that clock is delivered as differential signal; but this can also be for digital signals. Likely only to add when use case is there.
|
I've updated this PR to implement a complete interface for package pins as discussed. Key enhancements:
All tests are passing. Ready for review! |
|
Package Pin Interface
This PR implements a structured interface for determining package pins in ChipFlow.
Key Changes
Added abstract methods to define standard pin types in package definitions:
Implemented these methods in both package types:
Enhanced the Package class to:
Added comprehensive tests in test_package_pins.py
Created documentation in docs/package_pins.md
Backward Compatibility
The implementation maintains backward compatibility with the existing TOML configuration format while introducing a new, more flexible format.
Ready for Review
All tests are passing, and the implementation is ready for review.