Skip to content

Commit

Permalink
Various fixes regarding the new memory statment
Browse files Browse the repository at this point in the history
  • Loading branch information
@CircuitCoder
CircuitCoder committed Apr 25, 2023
1 parent c5b6867 commit e6311a7
Showing 1 changed file with 8 additions and 12 deletions.
20 changes: 8 additions & 12 deletions spec.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1671,7 +1671,8 @@ by the following parameters.
2. A positive integer literal representing the number of elements in the
memory.

3. A variable number of named ports, each having following parameters:
3. A variable number of named ports, each having the following parameters in
this order:
1. A read flag indicating the read capability of this port.
2. A write flag indicating the write capability of this port.
3. If the port can read, a non-negative integer literal indicating the read
Expand Down Expand Up @@ -1716,7 +1717,7 @@ mem mymem :
read => no
write => with-mask
write-latency => 1
custom-port => {a:UInt<4>, flip b:UInt<2>}
custom-port custom => {a:UInt<4>, flip b:UInt<2>}
```

In the example above, the type of `mymem`{.firrtl} is:
Expand Down Expand Up @@ -1869,17 +1870,12 @@ A memory with a constant data-type represents a ROM and may not have
ports with write capability. It is beyond the scope of this specification how
ROMs are initialized.


### Custom port

Custom ports are intended for post synthesis flows that require memory instances
to have additional control signals. Behavorial simulators should ignore these
ports, in the following way:

- All input signals (into the memory) should be treated as dangling
wires.
- All output signals (from the memory) have unspecified (implementation defined)
values.
to have additional control signals. During behavioral simulations, the behavior

This comment has been minimized.

Sign in to view

Copy link
@darthscsi

darthscsi Apr 28, 2023

Collaborator

The modeling here seems weird. If the additional control signals are required and do anything, presumably the user of the memory would have to be driving them? So the logic to connect them would have to exist in the firrtl.

I don't think anything else in the standard talks about behavioral simulation time. As a concept, this seems a big change.

Perhaps a different way of modeling the situation is:

TargetMemory = One Of
Module SimMem (extra ports, memory ports) {
  firrtl.mem
  other stuff
  }
  ExtModule TargetMem(extra ports, memory ports)

That is, don't try to force a generic memory to conform to arbitrary target specific memories, just blackbox the synthesis memory so you have what you need. If you want a simulation model, make one by extending the built-in memory with what you need to match closely enough the target specific memory.

TL;DR; I think custom ports is perhaps trying to solve a problem with the spec which should be solved in the design.
of custom ports is undefined. Behavorial simulators may reject custom ports,
either by a compilation error, or a runtime error.

## Instances

Expand Down Expand Up @@ -3656,8 +3652,8 @@ memory = "mem" , id , ":" , [ info ] , newline , indent ,
"data-type" , "=>" , type , newline ,
"depth" , "=>" , int , newline ,
"read-under-write" , "=>" , ruw , newline ,
{ "port" , "=>" , memory_port , newline } ,
[ "custom-port" , "=>" , type , newline ] ,
{ memory_port , newline } ,
[ "custom-port" , id , "=>" , type , newline ] ,
dedent ;
(* Force and Release *)
Expand Down

0 comments on commit e6311a7

Please sign in to comment.