airhdl Feature Requests
26 results found
-
Optional "accept" for write/read
Currently, user logic can not stall the register file, as soon as a read/write happens, the strobe will go high and one cycle later go low. If the user logic is not ready to take in/provide a value, the value might be lost. I think it would be nice to have an optional flag to have a handshake like AXI:
During a read, the strobe would go high, the statemachine would go into a READWAITREADY state, where the strobe is held high until ready is asserted from user logic. Only once that happens, the statemachine goes into READ_RESPONSE…3 votesThanks for suggesting this feature. For further analysis, it would be very helpful if you could provide a concrete application example for this. Thanks, Guy.
-
Make interrupt register outputs available to user logic
Please consider making interrupt register outputs available to user logic. Currently, there is no easy way for the user logic to know when an interrupt status bit is cleared by the ISR. This is critical to our application, and we cannot use mask bits or other signals to achieve the same result.
1 voteHi Scott, thanks for your suggestion. Would a one-bit output port computed as the logical OR of the interrupt register's bits do the job?
-
Add register input/output pipeline option using generic
Hello,
In order to help timing closure, it would be extremely helpful to add an option to insert extra register for input/outputs.
I suggest that each register (or array) would have a generic associated with the number of extra register pipeline we want to insert :GREG1OUTEXTRAPIPE := 0; -- no extra pipeline
GREG1INEXTRAPIPE := 0; -- no extra pipeline
GREG2OUTEXTRAPIPE := 1; -- 1 register per REG1 out field added
GREG2INEXTRAPIPE := 2; -- 4 register per REG2 in field addedThis will…
4 votesHi Guillaume, thanks for suggesting this. We'll be looking into it.
-
Unique Register Address when duplicating
When duplicating a register, it would be nice to have the new available address offset filled in the new register instead of the offset of the original one.
1 vote -
Hierarchical register structure
Allow registers to be put in a directory type structure.
8 votes -
Support bit-level RW access types
As is, access granularity is defined at the register level. However certain bits may require accessibility in ways that others may not. This is a recurring theme on many designs I have worked on.
I think it would be useful to specify for example, that Reg[7] is Read-only, while Reg[6] is Write-only, and Reg[5:0] is R/W.
6 votes -
Support longer text in register overview graphic
The visualization of the register fields arrays the text in a manner that renders it less than helpful unless all bit fields are shorter than 4 characters (except in the case of wider bit fields).
One solution might be to rotate field names 90 degrees and situate them vertically.
2 votesThanks for your suggestion. We’ll try to improve this aspect of the register overview in the future.
-
Option for synchronous reset of axi interface
To get the maximum performance, and smallest of a design the same type of reset should be used throughout the design, according to this document: https://www.xilinx.com/support/documentation/white_papers/wp275.pdf
This register generator currently uses asynchronous reset. It would be nice to have an option to use synchronous reset. If the reset of the design uses synchronous reset, all flip-flops would use the same type of reset and can be implemented directly into the flip-flop yielding better performance and are usage. Currently there is no way of changing the type of reset, which is unfortunate if used in a design that implements synchronous reset.
3 votes -
Add option to split register arrays and still create one single array output
Add the ability to split register arrays up in equal parts and generate single array output.
Ex.
Register:
| [7:0] | [7:0] | [7:0] | [7:0] |Each element in the array would be 8 bits long instead of 32, but still be apart of the same array.
Current solution would generate 4 different array outputs.
1 vote -
Wrap records on a register basis
Be able to select registers to be wrapped in records. This will allow the user to select only the registers he want to use records. The rest will use regular signals.
1 vote -
Add support for additional register types
Ability to support the following register types:
- write-1-to-clear status "sticky" bits
- write pulse acknowledge. Similar to the write pulse, but stays asserted until hw sends the ack which then clears the bit.6 votes -
uvmreg generation
generate uvm register format
4 votesHi, thanks for suggesting this feature. Could you please send us an example of how file should look like?
-
Support APB Interface
APB is used in Microsemi RISC-V designs.
5 votes -
Type cast registers
Ability to type cast registers i.e. signed or unsigned rather than stdlogicvector to be more descriptive.
2 votesThanks for the feedback!
-
Add an option for a Wishbone bus interface instead of AXI
Support the Wishbone bus in addition to AXI. It's free & open IP, it's very easy to interface to, and an excellent fit for many applications that don't need the sophistication of AXI.
The more complex Wishbone features such as stalls, retires, pipelining etc. need not be supported for this to have a lot of value.6 votes -
Add AXI burst functionality to bus interface
The AXI interface in the generated files currently doesn't support burst transfer. Could be added with a parameter for maximum burst size.
6 votes -
Any size register width
We use register widths of 64 or 128 in a number of cases. It would be nice if Airhdl could generate multiples of 32 bit register widths.
40 votes -
Generate C code driver templates
Aiirhdl should also generate c code templates to read/write any register.Currently only generates a header file (base address)
9 votes -
Support User Clocks
Add a user-clock input port to the register component, and handle the bus <-> user clock domain crossings in the component.
27 votes -
Add an option to sort bit fields MSB:LSB
Add a configuration option to display register bit fields sorted high to low, instead of low-to-high as is done now.
The proposed option should affect both the editor and in the generated documentation.1 votethanks for suggesting this!
- Don't see your idea?