Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 30 16:25
    Readon synchronize #1002
  • Jan 30 12:38
    Dolu1990 commented #1020
  • Jan 30 12:37
    Dolu1990 closed #1020
  • Jan 30 12:37

    Dolu1990 on dev

    fix #1020 Component.definitionN… (compare)

  • Jan 30 03:42
    Readon commented #973
  • Jan 29 19:04
    kleinai commented #973
  • Jan 29 14:30
    Readon commented #973
  • Jan 29 14:28
    Readon edited #973
  • Jan 29 13:01
    kleinai reopened #1020
  • Jan 29 11:48
    pavel-demin commented #1011
  • Jan 29 07:55
    aiit-linry commented #1020
  • Jan 29 07:51
    aiit-linry commented #1020
  • Jan 29 07:50
    aiit-linry commented #1020
  • Jan 29 00:04
    likewise commented #1011
  • Jan 28 05:19
    hanm2019 commented #1014
  • Jan 28 05:00
    hanm2019 synchronize #1015
  • Jan 27 12:06
    hanm2019 synchronize #1015
  • Jan 26 16:01
    jjyy-Huang synchronize #1010
  • Jan 26 15:51
    jjyy-Huang synchronize #1010
  • Jan 26 14:51
    likewise commented #1028
Dolu1990
@Dolu1990
<3
korbin
@korbin
def streamReadSyncRegistered[T2 <: Data](cmd: Stream[UInt], linkedData: T2, crossClock:Boolean = false) : Stream[ReadRetLinked[T,T2]] = {
    val ret = Stream(new ReadRetLinked(mem.wordType, linkedData))

    val retData = mem.readSync(cmd.payload, cmd.ready, clockCrossing = crossClock)
    val retLinked = RegNextWhen(linkedData, cmd.ready)

    cmd.ready := ret.ready

    ret.valid := RegNext(RegNext(cmd.valid))
    ret.value := RegNext(retData)
    ret.linked := RegNext(retLinked)
    ret
  }

i cannot for the life of me figure out how to remove the bubble from this extension to Mem.scala.

BRAM requires an additional register stage to be absorbed for better timing in Xilinx devices, so RegNext(retData) should work, but then the handshake logic breaks

Dolu1990
@Dolu1990
Ahh you want to have it with the bram output register enabled ?
korbin
@korbin
yes
exactly
Dolu1990
@Dolu1990
Do you have a clock enable on that output register in the FPGA ?
korbin
@korbin
i am not sure if they allow clock enables or not - i believe so
it may be different for block ram / ultraram
Dolu1990
@Dolu1990
If yes, i would say, just use the regular streamReadSync, and add a returnStream.stage()
korbin
@korbin
i was doing that, they don't get absorbed
Dolu1990
@Dolu1990
XD
damned
korbin
@korbin
in that case, i do not think clock enables are allowed
Dolu1990
@Dolu1990
Sadness of my life
hmm
what's about using a low latency fifo on the output ? with "almostfull" style logic to halt the cmd stream ?
korbin
@korbin
there are a number of places where there is register absorbing in xilinx FPGAs like this - BRAM, URAM, DSP, etc
the verilog needs to look like:
always@(posedge clk) begin
       ram_out <= ram[addra];
       dout <= ram_out;
end
it feels like there should be a way to skid buffer this somehow but i am just not familiar enough yet with Stream
Dolu1990
@Dolu1990
val haltIt = Bool()
val cmdHalted = cmd.haltWhen(haltIt)
val rsp = mem.streamReadSync(cmdHalted).queueLowLatency(size=2)
haltIt := rsp.isStall()
Something in that kind ?
(but not exactly)
More like :
val haltIt = Bool()
val cmdHalted = cmd.haltWhen(haltIt).toFlow
val rsp = mem.flowReadSync(cmdHalted).toStream.queueLowLatency(size=2)
haltIt := rsp.isStall()
(flowReadSync isn't a thing in the lib)
korbin
@korbin
yeah this makes sense, thanks
Dolu1990
@Dolu1990
Ahhh missing one thing
mem.flowReadSync(cmdHalted).stage.toStream.
sebastien-riou
@sebastien-riou
question to scala gurus:
we have elegant way to concatenate "reads": myBits_24bits := bits_8bits_1 ## bits_8bits_2 ## bits_8bits_3
do we have an elegant way to concatenate "writes" ?
I tried a ## b ## c = d but it does not seems to work, at least when a,b,c are registers
Dolu1990
@Dolu1990
(a, b, c) := d should work
@sebastien-riou
as long as d is Bits
saahm
@saahm
will that translate to the verilog equivalent? like {a,b,c} = sameVal[idx] where sameVal[idx] is same width as a, b and c together?
Dolu1990
@Dolu1990
yes, but with one assigment per destination
saahm
@saahm
I dont know if thats 'wanted' behavior, but components with the same name in different packages cause the same simWorkspace subdirectory to be used, is that wanted behavior?
Dolu1990
@Dolu1990
in SpinalSim or SpinalFormal ?
saahm
@saahm
SpinalSim
I only had it happen once and I didnt try reproducing it yet tho
Dolu1990
@Dolu1990
It isn't wanted behaviour
From a single run ?
or between multiple run ?
saahm
@saahm

So I have like

main/
|--foo
|    |--fooComp.scala
|    |--fooSim.scala
|
|--bar
     |--fooComp.scala
     |--fooSim.scala

in the the comp and sims are in different packages (also with the package statement at the head of the file). when I run the bar/fooSim it creates simWorkspace/fooComp, after that I run foo/fooSim and it overwrites the simWorkspace/fooComp from what I saw

Dolu1990
@Dolu1990
Ahh
yes it is expected
It would avoid the override if you were running them both in the same runtime
saahm
@saahm
like locking the directory?
Dolu1990
@Dolu1990
Yes
saahm
@saahm
ah ok
Dolu1990
@Dolu1990
and second one to come will be served with xxxx_1 as workspace
saahm
@saahm
when they are executed at the same time
Dolu1990
@Dolu1990
yes