<d1b2>
<rwhitby> To be honest, this is getting way out of hand. I'm considering removing the 1.2V feature altogether.
<d1b2>
<rwhitby> I don't know how I'll control all this stuff from the applet side, without having to modify existing I2C and UART gateware, instead of just using that gateware as-is.
<d1b2>
<rwhitby> When it was all on port B there was a chance (i.e. run Port A applet to set things up, then run Port B applet to do the comms).
<d1b2>
<rwhitby> But now that some control needs to be on port A, I think it's just too complex.
<d1b2>
<konsgn[no-Mic]> Don't do it! where there's a will there's a way!
<d1b2>
<rwhitby> Or maybe I have separate SBU1IN and SBU1OUT signals to Glasgow (taking all 8 ports for D+/D-/SBU1/SBU2) and have hard-wired uni-directional level shifters enabled by jumpers. Then no control signals are needed, and input or output is decided by which glasgow pins you assign to the uart applet.
<d1b2>
<konsgn[no-Mic]> might some combination logic help with this?
<d1b2>
<rwhitby> i need to kill the extra level of directional control.
<d1b2>
<konsgn[no-Mic]> the 1.2v is a uart right?
<d1b2>
<rwhitby> yes
<d1b2>
<konsgn[no-Mic]> so one of those lines gets pulled to 1.2v?
<d1b2>
<konsgn[no-Mic]> maybe a op-amp comparator?
<d1b2>
<konsgn[no-Mic]> sense the 1.2v on the tx line?
<d1b2>
<rwhitby> ok, now you're just driving me even further into complexity 🙂
<d1b2>
<rwhitby> 1.2V needed ? Just use the non-glasgow board that marcan is designing. Done.
<d1b2>
<konsgn[no-Mic]> sure, but you could use a quad opamp to detect a range of voltage and have that signal glasgow app.
<d1b2>
<rwhitby> Keep this board within the glasgow voltages. In the future, if glasgow then goes down to 1.2V, then this board automatically follows it.
<d1b2>
<konsgn[no-Mic]> haha hey, it's your spoons, use em wisely.
<d1b2>
<TomKeddie> @rwhitby I don't think you can run different apps on different porta but I might be wrong. You probably can import the other apps into your app and cherry pick the features you need though.
<d1b2>
<rwhitby> I'm thinking you run the control-fusb302 applet first, and it sets up the DUT. Then you run the uart applet separately, using Port B pins.
<d1b2>
<rwhitby> (until multi-applet support happens in the far future)
<d1b2>
<TomKeddie> Not sure the pins will retain their state though, the UART app will reload the fpga won't it?
<d1b2>
<rwhitby> ok, I'm going to check in this monstrosity (in case someone wants to fork it and descend deeper into the depths of complexity), and then look at simplifying it.
<d1b2>
<rwhitby> @TomKeddie for the FUSB302, it will hold the state as long as it still gets 5V.
<d1b2>
<TomKeddie> Ok, thanks, sorry to distract you.
<d1b2>
<rwhitby> but you're right - there's no way I could hold the A5/A6 state across multiple applet runs.
<d1b2>
<rwhitby> so that's another strike against the complex solution
<d1b2>
<rwhitby> @TomKeddie thanks for raising the issue - I handn't considered that fully.
<d1b2>
<rwhitby> there's the preserve option for voltages, so that's ok
<d1b2>
<TomKeddie> I think the applet part can be solved though, just need to get the schematic to do what you want. Perhaps a step back and list the features and look at their importance to you?
<d1b2>
<rwhitby> I don't think the applet part can be solved without forking the uart and i2c gateware, and I'm not really prepared to introduce that maintenance burden.
<whitequark>
what is 'forking gateware' here?
<d1b2>
<TomKeddie> It's likely other apps will any i2c and UART so it could be possible to move the for functionality into a library?
<whitequark>
I2C and UART are already effectively libraries; every applet is, though some are designed for it more explicitly. you can combine I2C and UART subtargets and put them both into your own applet
<rwhitby>
whitequark: yes, as long as I don't want to change their underlying functionality, right?
<d1b2>
<TomKeddie> ^ that's want I was suggesting just not articulating it so well.
<rwhitby>
and if I do separate inputs and outputs for each of the 4 signals, then I can just reuse the subtargets and assign the right pins.
<rwhitby>
but if I have to do complex directional stuff on the addon board, then that will likely require trying to hook into the insides of the uart or i2c libraries to expose the right signals to do the addon board directionality.
<rwhitby>
my goal is to combine the subtargets into my applet, and not touch the subtargets. that's currently working well for the i2c subtarget and the fusb302 applet.
<rwhitby>
I just need to add fusb302 interrupt support somewhere, but I don't see that impacting the reuse of the i2c or uart subtargets.
<rwhitby>
(I'm very aware of not increasing the maintenance burden of base glasgow in any way. That's why any talk of USB stack support is done by another connector that can talk to an external luna board. one board, one function, easy ways to connect boards together.
<whitequark>
rwhitby: you can provide pin instances to the subtarget that gives you separate i, o, oe
<whitequark>
this isn't currently documented and not always perfectly supported due to ongoing nmigen migration, but it *is* a legal API boundary
<rwhitby>
but I doubt I can go and drive the internal oe in conflict with what the subtarget wants to do
<whitequark[m]>
what is internal oe?
<rwhitby>
whitequark: I'm not saying that glasgow gateware wouldn't support what I need to do, I'm saying that what I need to do outside that subtarget is getting too complex?
<whitequark[m]>
I see
<d1b2>
<rwhitby> especially having to deal with two levels of direction control when using external bidirectional voltage translators.
<d1b2>
<rwhitby> so I'm considering simplifying to unidirectional level translating on the add-on board, so directional control is not required, and direction is determined by glasgow pin choice only.
futarisIRCcloud has joined #glasgow
<d1b2>
<TomKeddie> I feel like you're not the last person who is going to encounter this in building an add-on. It might help the platform to solve this cleanly.
<d1b2>
<rwhitby> the uart subtarget expects a fixed TX and RX direction, so there's no reason why the add-on board should have that dynamic.
<d1b2>
<Greg> Folks here have had bad experiences with the uni-directional level translators.
<d1b2>
<rwhitby> I thought the bad experience was automatic bidirectional?
<d1b2>
<Greg> (Sorry, auto sensing, bi-directional) uni should be fine. -_-
<d1b2>
<rwhitby> uni in and uni out, connected to separate pins on glasgow
<d1b2>
<TomKeddie> At its simplest the ability to supply a pin list to the oe would be sufficient I think?
<d1b2>
<rwhitby> coordinating the glasgow oe and the addon oe is the hard bit. especially if you add analog switches between direct and additional level shifted and needing to orchestrate safe defaults and safe transitions.
<d1b2>
<rwhitby> so I'm thinking of simplifying away the addon oe, so that it does become just a matter of giving the right pin lists to the glasgow subtargets
umarcor has joined #glasgow
<d1b2>
<konsgn[no-Mic]> Got the pins available for having a enable line for the uni-translators? say a target device was outputting audio on sbu lines.
<d1b2>
<rwhitby> what's glasgow going to do with audio?
<d1b2>
<rwhitby> there'll be a header, and you can take the signal over to your audio board
<d1b2>
<rwhitby> (there'll always be isolation headers for signals from the usb-c connector)
<d1b2>
<rwhitby> @TomKeddie @electronic_eel you are the two who have expressed interest in making or purchasing this board. Does 1.2v sit on your priority lists at all, or you wouldn't care if it's gone?
<d1b2>
<TomKeddie> I'm happy to take whatever you end up producing. Ideally I'd like to be able to do m1 with the board but the reality is I'm a long way from buying an m1 mac and once I do the need will be long past I expect. I expect I'll just be playing with PD mostly.
<d1b2>
<konsgn[no-Mic]> Nothing, but it may be good to turn off the translators so you are loading the lines as little as possible in case they have some analog goodness and you have a pin to spare.
<d1b2>
<konsgn[no-Mic]> ... not sure how much a buffer really loads the line though..
<d1b2>
<rwhitby> yes, the isolation jumpers will fully unload the line 🙂
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
DarthCloud has quit [Ping timeout: 268 seconds]
electronic_eel_ has joined #glasgow
electronic_eel has quit [Ping timeout: 264 seconds]
d_olex_ has quit [Read error: Connection reset by peer]
GNUmoon2 has quit [Ping timeout: 268 seconds]
d_olex has joined #glasgow
d_olex has quit [Ping timeout: 240 seconds]
d_olex has joined #glasgow
d_olex_ has joined #glasgow
d_olex has quit [Ping timeout: 256 seconds]
fibmod has quit [Ping timeout: 272 seconds]
fibmod has joined #glasgow
slurdge3 has joined #glasgow
infinigon_ has joined #glasgow
ZirconiumX has joined #glasgow
simukis__ has joined #glasgow
feldim2425_ has joined #glasgow
superbaloo_ has joined #glasgow
simukis_ has quit [*.net *.split]
superbaloo has quit [*.net *.split]
feldim2425 has quit [*.net *.split]
infinigon has quit [*.net *.split]
slurdge has quit [*.net *.split]
Lofty has quit [*.net *.split]
feldim2425_ is now known as feldim2425
slurdge3 is now known as slurdge
ZirconiumX is now known as Lofty
GNUmoon has joined #glasgow
<electronic_eel_>
rwhitby: so the problem with using the analog switches is increased applet complexity, as you'd have to change existing applets to support the control lines for the analog switches, correct?
<electronic_eel_>
but these control lines for the analog switchs are not expected to change fast and in sync with data signals
<electronic_eel_>
so how about using the pullups / pulldowns of glasgow to control them?
<electronic_eel_>
the pullups / pulldowns are controlled via i2c from the fx2, not from the fpga. so you don't have to change existing gateware to control them
<electronic_eel_>
also they will keep their state until explicitly reconfigured or the whole glasgow is reset
<electronic_eel_>
the pullups / pulldowns of glasgow are 10k. that should be plenty strong and reliable for the cmos inputs of the analog switches
samlittlewood has quit [Ping timeout: 240 seconds]
<electronic_eel>
rwhitby: had a look at your v0.7. saw just some small things.
<electronic_eel>
the via to gnd from D4 (tvs array for the lower usb port) is very far away. you want to put it near the array to lower inductance
<electronic_eel>
the safety-pulldowns for the analog switches are 1k. when you use my suggestion from before to switch the analog switches with the glasgow pulls then this is not gonna work
<electronic_eel>
i suggest something like 100k to be on the safe side
<electronic_eel>
the analog switches should have 100nF decoupling each
<electronic_eel>
you want everything to be in a "safe" state when you power the addon on, but don't have any direction or analog switch control signals set yet
<electronic_eel>
this means you should add pulls (i suggest 100k too) for the 1v2 level shifters too
<electronic_eel>
i mean their direction signals
<electronic_eel>
now comes the probably most controversial thing i saw: what is the best safe state you want the addon be in when you power it on but don't set control signals yet?
<electronic_eel>
currently it looks like you wanted to switch the analog switches to the 1v2 shifters and have them in input (from usb to glasgow) direction
<electronic_eel>
problem with this is that the 1v2 shifters are only rated for 3v3 volts. so if there was a 5v signal present on d+- or sbu, they could be damaged
<electronic_eel>
oh scratch that. changing the analog switch direction (as i was going to suggest) won't help with this as the 1v2 shifter is always connected to the glasgow side. so a 5v signal can always damage it
<electronic_eel>
so you can keep this as it is, just add the pulls for the dir signals
<electronic_eel>
while 5v signals are definitely possible on d-+ or sbu, they are not really common
<_whitenotifier-5>
[glasgow] whitequark commented on pull request #278: applet.selftest: fixes for revC0 and later - https://git.io/JtFFs
<electronic_eel>
you'd need a second analog switch for each signal to protect against 5v. don't know if that is worth it
<_whitenotifier-5>
[glasgow] TomKeddie commented on pull request #278: applet.selftest: fixes for revC0 and later - https://git.io/JtFFB
<_whitenotifier-5>
[glasgow] TomKeddie deleted a comment on issue #151: Selftest is not supported on revC - https://git.io/JtFi1
feldim2425_ has joined #glasgow
Eli2_ has joined #glasgow
kmehall has quit [Write error: Broken pipe]
awygle has quit [Write error: Broken pipe]
m42uko has quit [Quit: Leaving.]
emberian_z has quit [Quit: FIN]
nyanotech has quit [Quit: No Ping reply in 180 seconds.]
XgF has quit [Quit: No Ping reply in 180 seconds.]
jn__ has quit [Quit: No Ping reply in 180 seconds.]
feldim2425 has quit [Quit: ZNC 1.8.x-git-91-b00cc309 - https://znc.in]
feldim2425_ is now known as feldim2425
Rondom has quit [Remote host closed the connection]
spacekookie has quit [Quit: No Ping reply in 60 seconds.]
tobbez has quit [Remote host closed the connection]
cyrozap has quit [Remote host closed the connection]
jpa- has quit [Write error: Broken pipe]
tobbez_ is now known as tobbez
Dark-Star has quit [Quit: No Ping reply in 180 seconds.]
fridtjof[m] has quit [Ping timeout: 240 seconds]
DragoonAethis has quit [Quit: No Ping reply in 180 seconds.]
Twix has quit [Quit: Bye]
x56 has quit [Remote host closed the connection]
jn__ has joined #glasgow
Dark-Star has joined #glasgow
Nephirus has joined #glasgow
spacekookie has joined #glasgow
Rondom has joined #glasgow
promach3 has quit [Ping timeout: 240 seconds]
Spida has quit [Ping timeout: 240 seconds]
mwk_ is now known as mwk
deanforbes has joined #glasgow
disasm[m] has joined #glasgow
whitequark[m] has joined #glasgow
lambda[m]1 has joined #glasgow
_alice has joined #glasgow
randomplum has joined #glasgow
<d1b2>
<rwhitby> @electronic_eel: where does 1.2v sit on your personal list of priorities for this board?
<electronic_eel>
ah, right, i didn't answer that question
<electronic_eel>
i don't have an m1 mac and no plans getting one. so no immediate need for it
<d1b2>
<rwhitby> And is 1.2v in Glasgow's future?
<electronic_eel>
but i don't think other manufacturers may soon use usb-c alternate modes for debug interfaces too. and 1v2 saves them some silicon space for this
<electronic_eel>
*don't -> do
shoragan[m] has joined #glasgow
svenpeter has joined #glasgow
<electronic_eel>
1v2 is much more sensible to emi, noise and so on. so i don't see it in wide use for common interfaces soon. if you want low voltage, you go lvds
eddyb has joined #glasgow
<electronic_eel>
but for specialist / niche interfaces, like debugging interfaces, it could become more popular
<electronic_eel>
enhancing regular glasgow ports for 1v2 would mean a complete second row of level shifters for each port and an analog switch too
<electronic_eel>
so would cost lot's of board space and pins
<whitequark>
1v2 is not happening on revCD
<whitequark>
revE has a more modular design so it could work there
<electronic_eel>
yes, a addon board for revE would be possible
<electronic_eel>
you could just take the nearly same pcb and equip it with 1v2-3v3 shifters instead of the ones we have now
promach3 has joined #glasgow
<electronic_eel>
then you could swap these addons when you want to go down to 1v2
<d1b2>
<rwhitby> Are you saying that Glasgow is likely in future to support 1.2v natively, or are you saying it's not likely, so this board will be the means to work with 1.2v signals?
<electronic_eel>
1v2 native will be some years in the future. so having it on this board would be a plus
<whitequark>
you won't see 1v2 any time soon and you won't ever seen 1v2 with the same mechanical layout
cyrillu[m] has joined #glasgow
<d1b2>
<rwhitby> Next quesrion: would it be simpler if we remove the direction control, and just have separate input and output for each of d+/d-/sbu1/sbu2?
<electronic_eel>
how would that work? how should the shifter know when to drive and when not to?
<electronic_eel>
or am i missing something obvious here?
<d1b2>
<rwhitby> Maybe more jumpers
<d1b2>
<rwhitby> But yeah, it doesn't solve that easily.
jschievink has joined #glasgow
emily has joined #glasgow
_whitelogger has joined #glasgow
<d1b2>
<rwhitby> I'm a bit worried about the 5v blowing the level shifters. Do any exist which can tolerate 5v?
<electronic_eel>
yes, but they don't go down to 1v2
<d1b2>
<rwhitby> I think @Attie said he knew of some.
<electronic_eel>
i think it is a process limitation, the same cmos process just works well for a limited range
fridtjof[m] has joined #glasgow
<d1b2>
<rwhitby> So another option is a stand alone 1.2v board for Glasgow, to piggy back this board.
<electronic_eel>
hmm, you mean a general use 1v2 addon for glasgow?
<d1b2>
<rwhitby> But not sure how connector layout works for that.
<electronic_eel>
exactly, that is the problem of such a board. i probably would probably design it so that port a is the ios and port b is dir, so you end up with just one usable 1v2 port
<electronic_eel>
also you'd need some clever gateware mechanism to automatically propagate the dir signals for all the applets
<electronic_eel>
but i don't see a real need for such an addon yet. i haven't seen 1v2 cmos io used widely yet. but maybe i didn't look in the proper places
<electronic_eel>
so to sum it up, i think it is a good idea to put the 1v2 option directly on your addon as the m1 is one of the known usecases for 1v2 io
<electronic_eel>
and i think usb-c alternate mode for debug interfaces for mobile phones, tablets and pcs is a likely place for other 1v2 interfaces to creep up
<electronic_eel>
iirc intel already has some debug interface hidden in a special usb mode of their chipsets. not unlikely that they move that to usb-c once they properly support that
<whitequark>
it's not actually hidden
<whitequark>
both ehci and xhci debug modes are fairly well documented
FFY00_ has joined #glasgow
<electronic_eel>
in public non-nda documentation?
<whitequark>
yes? it's on usb.org
<whitequark>
the other half is in chipset docs iirc, let me check
<electronic_eel>
oh, didn't know that. i thought they pulled those docs some time ago. but i probably confused that
<electronic_eel>
but with access to wq lib or some search on the web one will probably be able to find them
FFY00 has quit [Ping timeout: 260 seconds]
<d1b2>
<Attie> re level shifters, I came across Nexperia 74AXP1T45 the other day... claims 0.9v - 5.5v range
<d1b2>
<Attie> i'm sure there are others... but i didn't fully dig into it yet though re speeds, etc...
<whitequark>
yeah sure, look at Intel® 7 Series Chipset Family Platform Controller Hub (PCH) §Intel® 7 Series / C216 Chipset Family Platform Controller Hub (PCH)
<whitequark>
er
<whitequark>
yeah sure, look at Intel® 7 Series Chipset Family Platform Controller Hub (PCH) §5.18.9.1.3
FFY00 has joined #glasgow
<whitequark>
that explains how to enable the EHCI debug port from your firmware or OS kernel
<whitequark>
it's the same for XHCI.
<electronic_eel>
whitequark: ok, i confused that with some other docs. so this interface is documented
<whitequark>
you might have been thinking of the ILA they have
FFY00_ has quit [Ping timeout: 258 seconds]
<electronic_eel>
@Attie the 74AXP1T45 looks interesting indeed. using it on glasgow would allow to go down with the supported io voltage range
<electronic_eel>
without big design changes
<electronic_eel>
but would of course need full re-qualification checks
<electronic_eel>
so nothing for revC3
<d1b2>
<Attie> i suggestion was really to put them on @rwhitby 's board, and use a similar VIO supply + DAC to alter the far-side I/O level
<whitequark>
interesting
<d1b2>
<Attie> that way it's fully under software control (no hardware config mismatch), and supports the full range
<whitequark>
we should look into 74AXP1T45 for sure
<whitequark>
(but later)
<electronic_eel>
rwhitby could also use them just to protect the shifters from 5v and keep the analog switch solution, without going full dac
<d1b2>
<Attie> i'm not sure how they'd fare against the TI parts we're already using, as they aren't spec'd at all for speeds, etc...
<whitequark>
yes, qualifying them would be quite difficult
<d1b2>
<Attie> (at least a quick look just now didn't provide the details i was after)
<whitequark>
perhaps they will publish those details later, or we can get a nexperia representative to give them to us
<d1b2>
<Attie> i would be surprised if they couldn't operate and keep up with a ~3Mbit UART for example
<d1b2>
<Attie> yeah, true
<whitequark>
i mean glasgow is not just for 3 Mbit UARTs
<electronic_eel>
oh yeah, they are quite new, rev 1 / june 2020
<whitequark>
but for rwhitby's purposes they'd probably work
<d1b2>
<Attie> oh yeah - my point was really that it can probably do that (M1 use case), but might not be able to do the ~100MHz we'd like on glasgow's direct pins
<whitequark>
right yeah
<electronic_eel>
i will add some samples of 74AXP1T45 to my next mouser order. then i can compare speeds, fault tolerance and so on to the ti shifters we have now
<d1b2>
<Attie> i look forward to the results 🙂
<electronic_eel>
rwhitby: one downside of using the 74AXP1T45 on your addon is that they aren't available at LCSC or JLCSMT. so when you use them, you wouldn't be able to have the addon fully manufactured by JLCSMT
<electronic_eel>
but they are pin and footprint compatible to the other 1t45 shifters, so the user could replace them later if they really want
<d1b2>
<rwhitby> right
<whitequark>
thanks electronic_eel !
<electronic_eel>
i haven't done anything yet, just dropped the part no into my shopping list :)
<electronic_eel>
there are a lot of interesting parts i want to check in there, so it could be some time till i come around to test them
<d1b2>
<rwhitby> I can ask @Greg to solder some on for me 🙂
GNUmoon has joined #glasgow
<electronic_eel>
they are sot-363, so i don't think you will need greg for them. desoldering the old with a big tip and a big blob of solder. soldering on the new ones with a regular tip
<electronic_eel>
desoldering with hot air would be the alternative of course
V has quit [Quit: We're here. We're queer. Connection reset by peer]
V has joined #glasgow
<electronic_eel>
rwhitby: are there still areas with your addon you are unsure about?
<d1b2>
<rwhitby> on a call now, will respond in about an hour
<electronic_eel>
no problem
<electronic_eel>
might be gone to bed by then, but just try it
egg|anbo|egg_ has joined #glasgow
<d1b2>
<Greg> I'm a local, and also already soldering the QFNs on these boards. So it's not an issue.
Spida_ is now known as Spida
egg|anbo|egg_ has quit [Remote host closed the connection]
smkz has quit [Quit: test]
Mars is now known as Twix
<d1b2>
<rwhitby> @electronic_eel: I don't think there are any residual concerns. If there are gateware experts who are keen to have the 1.2v interfaces working, then I'm more comfortable about not having to go it alone on that side. I'm fully ok on the PD side, but the gateware interfacing for the 1.2v direction stuff scares me a bit 🙂
smkz has joined #glasgow
<d1b2>
<rwhitby> so it sounds like the only changes I need to make on 0.7 is to change the 1K pull-downs to 100K on the analog switches (so we can use glasgow pulls to control them) and add safety pulls on the direction signals. then the 5v tolerant level shifters solves the 5v issue.
<d1b2>
<rwhitby> oh, and 100nF decoupling for analog switches
<electronic_eel>
i am far from a gateware expert. but as i said, you could start with using just the pullups/downs for the direction stuff. so no gateware changes necessary.
<d1b2>
<rwhitby> and the gnd via for tvs
<electronic_eel>
you won't get fast direction changes, but for uart this isn't an issue
<d1b2>
<rwhitby> right
<electronic_eel>
and once you really need the fast direction changes, one could extend the gateware
<electronic_eel>
so i think the scary stuff can be left for later ;)
<d1b2>
<rwhitby> so I need to fit 4 more resistors and 4 more caps.
<electronic_eel>
you have tons of space left, so i don't see an issue there
<d1b2>
<rwhitby> "tons" is relative to pcb layout experience 🙂
<electronic_eel>
if you'd let greg layout this, he'd use wlcsp parts and 6 layers and cram the whole thing in 1/4 the space
<electronic_eel>
...or less
<d1b2>
<rwhitby> maybe I move to 0402 discretes instead of 0603
<electronic_eel>
the layout is constrained basically by the glasgow port distance. this leaves enough space. don't think it is worth the effort of changing the layout to 0402 now
<d1b2>
<rwhitby> ok, looks like I've got some polygon pushing to do over the weekend.
<electronic_eel>
have fun!
<d1b2>
<rwhitby> thanks again for all your helpful review
<electronic_eel>
you are welcome
<d1b2>
<TomKeddie> @rwhitby you could move to keyed smd sockets for the connection to the Glasgow, not recommending it necessarily....
Nephirus has quit [Ping timeout: 260 seconds]
<d1b2>
<Attie> that wouldn't help (keys are rotationally symmetrical / both on the inside)
<d1b2>
<rwhitby> he's thinking to make more space on top