<sb0>
_florent_, with the GTP transceiver, as I read the doc, RXDLYBYPASS should be 0 when RX buffer bypass is used
<sb0>
rjo, in your sfp_gtp definitions, I assume that txp/txn is an output for the FPGA
<sb0>
this is the general convention in migen, e.g. serial and drtio also follow that
<sb0>
rjo, combining ethernet and drtio on a single kasli board is going to be a mess
<sb0>
they managed to make the gtp trash even worse than the gtx trash, and they removed the channel PLLs, so both PLLs (for ethernet and drtio) have to be combined into a single GTPE2_COMMON
<FelixVi>
cr1901_modern: are you around?
<cr1901_modern>
FelixVi: Yes, but currently do not have the bandwidth for q's, sorry.
<FelixVi>
cr1901_modern: No worries, hopefully I can catch you tomorrow. Have a good night
<FelixVi>
or let me know if you do later on ;)
<cr1901_modern>
Won't be before I sleep... whenever I manage to do that
<FelixVi>
I'd help out if I could. Well, I can just not bug you for a while... Feel like I got plenty of questions in recently
<FelixVi>
I'd RTFM if there was one ;)
<cr1901_modern>
I know I know
<cr1901_modern>
And thanks for the offered help anyway. Not much I can do about shit sleep patterns
<FelixVi>
Actually it's probably better to read source anyways...
<FelixVi>
Well, food and herbal tea often dies the trick
<FelixVi>
*does
<cr1901_modern>
I mostly drink black tea
<FelixVi>
that has caffeine, probably not the best idea past 5 or 6
<cr1901_modern>
oh it's decaf
<FelixVi>
ah nvm then :)
<cr1901_modern>
Just your run-of-the-mill decaf orange pekoe
<sb0>
FelixVi, look closer
<sb0>
Requirement: 3.888ns
<sb0>
Source Clock: sys_clk rising at 0.000ns
<sb0>
Destination Clock: sdram_half_clk rising at 3.888ns
<sb0>
that's wrong
<sb0>
of course you won't get 3.8ns routing from cpu to dram phy in slowtan6
<FelixVi>
sb0: I thought it's fine because the CPU generates the address and it's clocked out on the ddram clock
<sb0>
there's either a missing register, wrong clock constraints, or pll configuration issues
<FelixVi>
it's from the load_storage module of the cpu
<sb0>
#1 would be a bug in misoc
<FelixVi>
sb0: uh - I'll double check
<FelixVi>
I'm thinking it's because I use BRAM for the bios
<FelixVi>
Is there a one-sentence instruction for how to use flash instead of bram?
<FelixVi>
looking at the layout, there's a lot of BRAM slices all over the place which makes it hard to optimize
<FelixVi>
I already nailed down all the address and ctrl FFs right by the PADS to even out delays
<FelixVi>
that actually seems to help
<cr1901_modern>
Some sort of combination involving integrated_rom=False, add_memory_region(flash_wishbone_interface)
<FelixVi>
yeah, at least I seem to be getting closer
<FelixVi>
is the flash boot address always fixed?
<FelixVi>
and and kernel boot address would be the program I upload?
<FelixVi>
that's one thing I should try
<cr1901_modern>
It shouldn't be always fixed, and yes you'd upload to the kernel boot address
<FelixVi>
k, so flash boot address is where the bios goes and kernel boot (flterm) is where the program goes
<FelixVi>
I'll give that a shot, feel like it'll move things along
<FelixVi>
Dealing with anything other than a ddram controller for a change would be awesome
<FelixVi>
all one's and zero-one's are already good, but the random address test is the one that likes to fail
<FelixVi>
either way, I'll check on the other things sb0 suggested tomorrow by comparison to mimasv2
rohitksingh has joined #m-labs
<FelixVi>
what is the purpose of dummy and div in spi_flash?
<GitHub83>
[artiq] sbourdeauducq commented on pull request #855 89279be: Trivial style issue, but I think it should be first in that list, since this is the first thing that gets accessed. https://github.com/m-labs/artiq/pull/855#discussion_r153039059
<sb0>
rjo, also vivado cannot trace clock constraints through transceivers anyway
<sb0>
the constraints have to be at the transceiver outputs (txoutclk and rxoutclk)
<sb0>
that's another example of poor integration of the transceiver with the fpga... it's like they hired a completely different team to build that thing and they had no idea how programmable logic works
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<rjo>
sb0: seeding the constraints where it starts to matter for p&r seems fine to me.
<sb0>
it can matter before - you can route IBUFDS_GTE2 (which is before the transceiver clock input) to the fabric
<sb0>
in which case I guess you need two redundant constraints
<rjo>
sb0: for RX you'd still probably constrain rxoutclk
<sb0>
rjo, nope. the rx cdr has a very narrow range (tenths of %).
<sb0>
and still on the topic of the rx cdr, it can't even tell you when it's locked, so if you want to do some rate autodetection you have to try every possible rate until you receive data that makes sense ...
<rjo>
that seems intrinsic to CDR. i could see it locking happily to multiples and submultiples. i.e. locking doesn't mean much.
<rjo>
but yes. i guess they should have considered using the xceiver clocking config and constraints on the clock inputs to derive constraints for txoutclk etc
FelixVi has joined #m-labs
<FelixVi>
does "sayma" have two flash ics?
<FelixVi>
Does flash_boot_address need to be larger then the main bitstream_address + bitstream_length?
<cr1901_modern>
FelixVi: Yes. The CPU address need not be larger than bitstream_address + bitstream_length if booting from flash, however
* cr1901_modern
still feels like crap and is not available for thinking today
<FelixVi>
cr1901_modern: Yeah, I've tried that and can't figure out what's wrong
<FelixVi>
I'll leave it alone for now - hopefully I'll have time to revisit it soon
rohitksingh has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<FelixVi>
cr1901_modern: I updated the Issue about Papilio flash with what I've been trying to do
<FelixVi>
As is, the Papilio Pro platform *appears* to be broken