<digshadow>
azonenberg: have you looked at the SEM IP core?
<azonenberg>
digshadow: no i have not
<digshadow>
TBH it will probably provide better direction than I can give
<azonenberg>
for the short term i'm just trying to create a portable IP block that can identify what fpga it was compiled for
<azonenberg>
i'll look
<azonenberg>
and pull off information like stepping number
MarcelineVQ has joined ##openfpga
emeb_mac has quit [Ping timeout: 245 seconds]
<mwk>
azonenberg: just a cargo cult idea: Xilix bitstreams have two words of ffffffff between the bus width detection thing and the sync word
<azonenberg>
i'll try that, but i dont think the BWD is even required in x32 mode
<azonenberg>
And the sync word is being accepted because the status output changes from d9 to db
<mwk>
true
<mwk>
I don't know if it's even recognized on the ICAP
<mwk>
hm
<mwk>
what device is that?
<azonenberg>
7a100t right now
<azonenberg>
it is recognized, the icap allows 8/16/32
<azonenberg>
its basically selectmap minus the bidir buffer on the data bus
<azonenberg>
so you get separate din/dout
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<mwk>
azonenberg: cannot come up with anything other than "should work"
<mwk>
could be something stupid
<mwk>
clock too high?
<azonenberg>
100 MHz, which is max in the datasheet
<azonenberg>
slowign to say 50 with a pll is on the to-try list but it makes timing
freemint has joined ##openfpga
<mwk>
alright, I give up
<mwk>
ICAP's haunted
<mwk>
the simulation models (WHY are there two different ones) are a huge mess wirrten to sort-of mimic the behavior of the hardware, but probably don't have all that much resemblance to the real thing...
_whitelogger has joined ##openfpga
<azonenberg>
mwk: yeah
<azonenberg>
i wish they'd just secureip the actual HDL with the parts that talk to the rest of the chip commented out or something
<azonenberg>
like, as much as i hate secureip at least then it would be an accurate model :p
<azonenberg>
and i'll take an accurate black-box model over one that i have source to, but doesn't work
<mwk>
azonenberg: another thing I'd try is getting rid of that RDWR_B = 0 CSI_B = 1 cycle
<mwk>
but probably grasping at straws here
<azonenberg>
my understanding is that that was mandatory
<mwk>
you have to have a CSI_B = 1 gap cycle, yes
<mwk>
but one should be enough
<mwk>
it's not an async interface, after all
<azonenberg>
the one forum post i found with any hints on the issue made it seem like you could only change rdwr when cs was deasserted, not asserted and not concurrently with it changing
<mwk>
the whole thing is cargo-culted because the documentation is shit
* pie_
eats dessert bits
<mwk>
mmmm deassert bits
<azonenberg>
mwk: saying the documentation is shit implies there is documentation
<azonenberg>
:p
<azonenberg>
There is a description of the pins on the icap primitive in the libraries guide and... that's about it
<mwk>
UG470
<mwk>
but yeah
<azonenberg>
UG470 doesnt even give timing diagrams
<azonenberg>
it vaguely hints that the icap is similar to selectmap
<mwk>
well I'm referring to the config machinery in general
<mwk>
UG470 describes the registers and their btifields, more or less
<mwk>
what it doesn't really tell you is what kind of strange pipeline effects each of them has
Flea86 has joined ##openfpga
<mwk>
and if you look at an actual bitstream, you see nops, dummy words, dummy frames, dummy words in frames, and gods help you if you don't get it exactly right
<azonenberg>
yes, i know - i've written my own jtag configuration logic
<azonenberg>
and *that works*
<azonenberg>
Which is why i am so confused as to why i cant get it to work over the icap
<azonenberg>
i found bugs in UG380 doing this
pie_ has quit [Ping timeout: 252 seconds]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
<ZipCPU>
azonenberg: How's that ICAPE2 core going?
<ZipCPU>
Looks like you've been busy at it all night without making much progress ... (?)
<ZipCPU>
Also, a comment you made above, the clock for the ICAPE2 is limited to 50MHz... at least for my A7 devices
<ZipCPU>
I typically generate this clock from a 100Mhz system clock--probably not necessarily a good idea, but it's worked for me so far
mifune has joined ##openfpga
constantin has joined ##openfpga
freemint has quit [Ping timeout: 250 seconds]
freemint has joined ##openfpga
freemint has quit [Ping timeout: 258 seconds]
Flea86 has quit [Quit: Leaving]
freemint has joined ##openfpga
genii has joined ##openfpga
pie_ has joined ##openfpga
constantin has quit [Remote host closed the connection]
emeb has joined ##openfpga
carl0s has joined ##openfpga
<azonenberg>
i'll try dividing but it passes timing at 100
<azonenberg>
which is the upper limit per datasheet
<ZipCPU>
Hmm ... okay, my data sheet had said 50MHz as I recall
<ZipCPU>
That's why the core had the clock divider within it (I'd never build it that way again ...)
<azonenberg>
DS181 table 66
<azonenberg>
top of page 58 in my version
<azonenberg>
(heading out to work bbiab)
<mwk>
hmm
<mwk>
ZipCPU: maybe you're thinking of Spartan 6? that one seems to have a 50MHz limit for some config-related clocks
<ZipCPU>
azonenberg: Looks like my memory was faulty on that one, since my version says 100MHz as well
<ZipCPU>
mwk: You might be right there
<mwk>
(the datasheet doesn't mention ICAP itself)
<ZipCPU>
Although ... my data sheet has clock speeds ranging from 70MHz - 100MHz, so 50MHz should be safe for both
azonenberg_work has quit [Ping timeout: 250 seconds]
<mwk>
also, hilarious
<mwk>
the spartan 6 datasheet mentions max frequency as low as 12MHz if you intend to readback block RAM contents using ICAP/selectmap
<mwk>
4MHz for low-power version, even
<mwk>
DS162
<mwk>
page 54
dh73 has joined ##openfpga
yhetti_ is now known as yhetti
azonenberg_work has joined ##openfpga
<azonenberg_work>
ZipCPU: back
<azonenberg_work>
And yeah i havent made a ton of progress
<azonenberg_work>
i think i'm gonna put the icap stuff on ice for a day or two, see if anyone else can come up with hints, and work on getting the fpga and stm32 talking to each other
<azonenberg_work>
I have an RMII interface i'll be using for higher bandwidth traffic (e.g. TFTP firmware updates) and SSH console down the road, but i also have a UART i'll be using for control plane traffic that i need to come up with a protocol and command set for
<azonenberg_work>
actually two, one to the management board fpga and one to the switch fabric fpga, but the switch fabric pcb doesnt yet exist
<azonenberg_work>
So i'm gonna focus on bringing up the management side
<whitequark>
is this still the 10g switch?
mumptai has joined ##openfpga
azonenberg_work has quit [Ping timeout: 268 seconds]
m_w has quit [Ping timeout: 245 seconds]
dh73 has quit [Ping timeout: 260 seconds]
m_w has joined ##openfpga
azonenberg_work has joined ##openfpga
<azonenberg_work>
whitequark: yes
<azonenberg_work>
I'm trying to add support for the management CLI to show which FPGA is on each of the various boards
<azonenberg_work>
the CPU has no access to jtag so i figure i can query via the icap
<whitequark>
ah
<azonenberg_work>
sure i could bake a hard coded constant in and query via uart or something
<azonenberg_work>
but i figure having a block that works via ICAP is better as i can throw it in any design i want and it will always read correct
<azonenberg_work>
(plus it lets me query die stepping at run time)
<azonenberg_work>
whitequark: also its not really a proper 10G switch
<azonenberg_work>
its a 1G switch with a handful of 10G uplinks
<azonenberg_work>
I plan to make an all-10G switch with one or two 40G uplinks in the future using most of the same HDL on a faster FPGA
<whitequark>
ah
<azonenberg_work>
But right now i have a relatively new (end of sale but not EOL) cisco with 48x 10G + 4x 40G) secondhand cisco as my core switch and am in no hurry to replace it, although it does sound like a jet engine so that's one reason :p
<azonenberg_work>
My edge switches are 24x 1G copper + 4x 1G optic (no 10G whatsoever) and were EOL'd in 2006
<azonenberg_work>
So my first upgrade priority is to replace those with something that has 10G uplinks, rather than having 24 1G ports sharing a single 1G uplink to the core
<azonenberg_work>
Which is where LATENTRED comes in
<azonenberg_work>
Once i get the HW/SW fully debugged on the prototype, i'll build two more and swap out all of the 1G ciscos in my actual network
<azonenberg_work>
Then start thinking about building LATENTORANGE, the 10/40G one
<azonenberg_work>
LATENTRED uses an INTEGRALSTICK for management, three 8x SGMII line cards that i've designed but not fabbed, a switch engine PCB i have yet to design that will probably have a 7k160t-2fbg484c on it
<azonenberg_work>
and a TBD interconnect
<azonenberg_work>
original plan was a long bar shaped passive backplane going between samtec QTH connectors on the switch engine and the 3 line cards
<azonenberg_work>
I'm now considering cutting the costs of the backplane and making it far easier to solder, although adding slightly more connector losses, by switching to a daisy chain design
<azonenberg_work>
where each line card will take in 24 lanes of SGMII, feed 8 to the local PHYs then push the other 16 onto the next card via either a direct board-to-board connection or a short "jumper" board like an SLI bridge
<azonenberg_work>
that was bluezinc's idea and i quite like it, i was worried about soldering a board that long b/c it wouldnt fit in my oven
<whitequark>
interesting
<azonenberg_work>
right now i am working on writing the firmware for the management card and taking a break from hardware while i fit out my new lab
<azonenberg_work>
i have devkits and parts strewn all over the place because i'm unpacking boxes of stuff from the move, but don't have all my cabinets and shelving set up yet
<azonenberg_work>
so i dont want to add more boards to the mix until i have somewhere to store what i have
<azonenberg_work>
I might clean house a bit and sell off/give away a bunch of my spartan3/6 stuff
<azonenberg_work>
i dont see ever doing a new design on them in the future
<azonenberg_work>
as far as UI goes there will be a dedicated RJ45 management port using the cisco RS232 pinout since that seems to be de facto standard for networking gear still and is much smaller than a DB9
<azonenberg_work>
then a dedicated 1000base-TX interface, bridged to RMII on the management FPGA (the PHY is tri speed but the STM32 can't go past 100M, I will probably set the PHY to negotiate 10/100 only so i dont have to speed shift)
<azonenberg_work>
first round firmware will be rs232 only, then i'll bring up telnet, then eventually ssh
<azonenberg_work>
that will probably take a while as i dont think anyone makes a sshd that runs on a bare metal system with no filesystem or dynamic memory allocation
<azonenberg_work>
i may have to write one
<azonenberg_work>
but since its a physically isolated network, i wouldnt be too sketched out about having telnet-only management especially during development before i have it connected to anything important
<azonenberg_work>
(there is, by design, no bridging from the management port to the switch fabric)
<azonenberg_work>
The management firmware is my first embedded software (vs HDL) project in close to ten years so i'm trying some new things, it's also my largest embedded software project by far even now
SpaceCoaster has quit [Quit: ZNC 1.6.5+deb1+deb9u2 - http://znc.in]
SpaceCoaster has joined ##openfpga
craigjb has quit [Ping timeout: 268 seconds]
Jybz has joined ##openfpga
genii has quit [Quit: Golf, Leafs, Golf! ... Go Raps!]
freemint has quit [Ping timeout: 250 seconds]
rohitksingh has joined ##openfpga
freemint has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
Jybz has quit [Quit: Konversation terminated!]
emeb_mac has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
mumptai has quit [Remote host closed the connection]
carl0s has quit [Remote host closed the connection]